Automator on a Mac: the small jobs worth handing over

Automator is still in the Applications folder, it still opens, and the first screen still asks a question that is hard to answer from cold: which type of workflow is this. Meanwhile Shortcuts has arrived on the Mac, does much of the same work, and syncs across devices. The obvious question is whether Automator is worth learning at all in 2026.

It is, for a narrow set of jobs, and the narrowness is the point. Automator earns its place on repetitive file work that is triggered from the Finder, and it loses to Shortcuts almost everywhere else. Knowing which side of that line a task falls on takes one reading, and it saves building the same automation twice.

What Automator still is, and where Shortcuts took over

Both apps build a sequence of steps by dragging them into a list. The difference is where the sequence can be triggered from and what it can reach.

Tool Runs on Best at Weak at
Automator Mac only File and folder work triggered from the Finder Sharing, syncing, anything involving a phone
Shortcuts Mac, iPhone, iPad Anything that should exist on more than one device Some older Mac specific actions
Shell script Mac only Text processing, anything repeated hundreds of times Being triggered by a person who is not in a terminal

Apple's position on the relationship is not ambiguous. The Automator guide points directly at the other app.

Shortcuts can convert most Automator workflows into shortcuts that carry out the same functions, events, and automations. Source: support.apple.com, read September 27, 2026

That sentence answers the strategy question. Anything built in Automator is not a dead end, because it can be carried across later. Time spent in Automator on a genuinely useful workflow is not wasted even if the work eventually moves. Apple documents the move in one direction only, so a workflow that might end up on a phone one day is still better started here than not started at all.

The jobs that actually pay back

The reason most people open Automator once and never return is that they open it without a job in mind. The Library on the left is organised by the app the actions belong to, which is only useful once there is something specific to do.

Four shapes of task are worth the effort, and they have something in common: they happen on a batch of files, they are triggered while looking at those files, and the steps never change.

Renaming a batch of files is the first and the most used. Camera exports, scans and downloads arrive with names that are unusable in a week, and the Finder actions can add a date, add a sequence number, or replace part of every name in one pass.

Resizing or converting a folder of images is the second. Anything that involves a fixed maximum width and a consistent format is the same three actions every time, and the only variable is which folder.

Combining PDFs is the third, and it is the one worth building even for occasional use, because the manual version involves a preview window and a lot of dragging.

Moving and filing is the fourth. Sorting a folder by kind, moving anything older than a certain point into an archive folder, or emptying a staging folder into named destinations are all short sequences.

What these have in common is worth stating plainly, because it is the filter for every future idea: the job must be mechanical, the decision must already have been made, and the number of files must be more than one. A task that requires looking at each file and deciding something is not a candidate, no matter how repetitive the surrounding clicks are.

Choosing the workflow type is choosing the trigger

The dialog that appears at File and then New is where most first attempts go wrong, because the choice looks like a formality and is actually the most consequential decision in the whole build.

Apple's guide notes that "when you select a workflow type, its description is shown in the workflow type menu," so the descriptions are there to be read rather than skipped. The choice does not change what the workflow can do. It changes how it gets started, and therefore whether it ever gets used.

Quick Action, for anything triggered from the Finder

This is the type that earns Automator its keep. A saved Quick Action "is then available from Finder windows, the Services menu, or the Quick Actions menu," which means the workflow lives where the files are.

The practical effect is that a batch rename becomes a right click on a selection of files. Nothing has to be opened, no folder has to be chosen, and the workflow operates on whatever was selected. Any automation that acts on files the person is already looking at should be a Quick Action and nothing else.

Application, for a drop target

Saving as an application produces something that runs when files are dropped onto it. That suits a workflow that has one specific input folder or one specific person using it, and it can sit on the desktop or in the Dock. It is the easiest type to hand to somebody else, because it looks like an app rather than like a script.

Folder Action and Calendar Alarm, for the ones nobody triggers

These two attach the workflow to something other than a click. A Folder Action runs when items are added to a particular folder, which is how a downloads folder sorts itself. A Calendar Alarm runs from a calendar event, which is how something happens weekly without anybody remembering.

Both are more fragile than the first two, for the same reason: when they fail, nothing tells anybody. A Quick Action that breaks produces an error in front of the person who just clicked it. A Folder Action that breaks produces a folder that quietly stops sorting.

Building one, and watching it run

The build itself is short. Actions are added by double clicking them in the Library, they arrange into a sequence, and the settings for each one are on its own card.

Running it is the part worth doing carefully the first few times. "After you add your actions and configure the settings, you can try out your workflow by clicking Run." The workflow then executes from the top, running each action in sequence, with status messages appearing in the Log area and green checkmarks marking the actions that completed.

That log is the whole debugging story. An action that fails stops the sequence at a visible point, which is far more informative than a script that exits with a status code nobody sees.

Two features in the guide are worth knowing about before they are needed. Variables hold a value produced by one action so a later action can use it, which is what turns a fixed sequence into one that adapts to its input. The Loop action repeats part of a workflow, which matters for anything that has to keep going until a condition is met rather than run once.

Test on copies. Most of the useful actions here move, rename or overwrite files, and a workflow that does the wrong thing to forty files does it in under a second.

Where scripts come in

Automator can run scripts as actions, and the guide has a page for it. That matters for two different reasons.

The first is that a single action can carry a shell command or an AppleScript, so a workflow that is ninety percent standard actions does not have to be abandoned because of one step nothing covers. The awkward step becomes a script action in the middle of an otherwise ordinary sequence.

The second is more useful in practice. Anybody who already writes shell scripts can use Automator purely as a trigger and a user interface: the script does the work, and the Quick Action wrapper gives it a place in the right click menu and a way to receive whatever files are selected. That combination is often better than either half on its own, because the hard part of a shell script is rarely the logic and usually getting it started with the right arguments at the right moment.

When to move a workflow to Shortcuts

Importing is deliberately trivial. "You simply drag a workflow file into Shortcuts and the conversion happens automatically," and "your imported workflow appears as a new shortcut."

The caveat is in Apple's own wording. "Shortcuts can convert most Automator workflows into shortcuts that carry out the same functions, events, and automations." Most, not all. A workflow that leans on an older Mac specific action can come across without working, which is why the sensible order is to import and test rather than import and delete.

The decision itself is short. Move it if the same job is wanted on an iPhone or an iPad, if it should sync between Macs, or if it needs to be triggered by something Automator cannot see, such as a time of day away from the calendar or an arrival at a location. Keep it in Automator if it is a Quick Action on files in the Finder and it already works, because that case is exactly where Automator remains the cleaner fit.

The automation that never stops running

There is a cost to automation that the guides do not discuss, and it shows up on the Mac rather than in the workflow.

An Automator workflow runs when triggered and then exits. Nothing stays resident, nothing appears at the top of the screen, and the machine is unchanged a second later. That is a real advantage over the usual alternative, which is a third party utility that watches folders, watches the clipboard or watches for a key combination, and therefore has to be running at all times with an icon in the menu bar to prove it.

Three or four of those utilities is how a menu bar runs out of room, and on a MacBook with a notch the items simply stop being reachable. The honest comparison, when deciding between a workflow and an app, includes that permanent line item. A workflow that is used twice a week and costs nothing between uses often beats a utility that does it slightly better and takes a place in the menu bar forever. For the resident tools that genuinely earn their keep, the features page covers keeping their icons available without keeping all of them visible, and how it compares sets out the differences between the tools in that category.

What to change first

Pick one job that happens on more than one file at a time, build it as a Quick Action rather than as anything else, and test it on copies. If the result is that the Finder right click menu does the work instead of another resident utility, that is the better trade twice over, and for the utilities that stay, Koffret keeps their icons out of the way until they are wanted.

Frequently asked questions

Is Automator still supported on macOS in 2026?

Yes. Automator ships with macOS and Apple maintains its user guide, including a page on importing workflows into Shortcuts. New automation work is being pointed towards Shortcuts, but existing workflows keep running and Quick Actions triggered from the Finder remain the case where Automator is still the natural fit.

What is the difference between Automator and Shortcuts?

Automator runs on the Mac only and is strongest at file and folder work triggered from the Finder. Shortcuts runs on Mac, iPhone and iPad and syncs, which makes it the better choice for anything wanted on more than one device. Automator workflows can be dragged into Shortcuts to convert them, and Apple notes that most of them convert successfully.

Which workflow type should I choose in Automator?

Choose Quick Action for anything that acts on files selected in the Finder, because it appears in Finder windows, the Services menu and the Quick Actions menu. Choose Application for a drop target, Folder Action for something that should run when items land in a folder, and Calendar Alarm for something that should run on a schedule.

Do I need to know how to code to use Automator?

No. Actions are added by double clicking them in the Library and arranged into a sequence, and the Run button shows progress in a log area with checkmarks for completed steps. Scripts are available as an action for steps that nothing else covers, which makes them optional rather than a starting requirement.

Can an Automator workflow delete or overwrite my files?

Yes, which is why a new workflow should be tested on copies. Many of the most useful actions rename, move or replace files, and a workflow runs through a whole selection in a fraction of a second. Building against a duplicate folder first costs nothing and removes the only real risk in this kind of automation.

Back to all posts