Automator on an Apple Mac: turn a folder chore into one click

Most advice about Apple Automator now opens by pointing at Shortcuts and suggesting the reader move on. That advice is half right, and the missing half is the part that matters to anyone with a folder that fills up. Apple has encouraged the move to Shortcuts since macOS Monterey and has kept Automator fully supported alongside it, which sounds like a straightforward succession. It is not, because one trigger never made the crossing.

Automator has shipped with macOS since Mac OS X Tiger. The reason to open it in 2026 is narrower than it was, and also more definite: it is the documented route for a chore that should start by itself when something arrives in a folder.

The trigger list is what settles the choice

Apple's Shortcuts guide lists what a shortcut on the Mac can react to. The automation intro describes running actions based on events such as time of day, arrival at a location, or the opening of an app. The page on adding automations enumerates the triggers that can run without asking for confirmation: Time of Day, Alarm, Sleep, Arrive, Leave, CarPlay, Email, Message, Transaction, Wi-Fi, Bluetooth, Apple Watch Workout, NFC, App, Airplane Mode, Do Not Disturb, Low Power Mode, Battery Level, Charger and Sound Recognition.

Read that list looking for a folder. It is not there.

What should start the work	Automator	Shortcuts
A file arriving in a folder	Folder Action	No documented trigger
A file selected in the Finder	Quick Action	Quick Action, via the Services menu
A time of day	Calendar alarm workflow	Time of Day automation
A spoken phrase	Dictation Command	Siri
Double clicking an icon	Workflow saved as an application	Run from the app or Spotlight

The two right hand columns explain why the general advice to switch is sound and why it fails for this specific case. Anything triggered by time, place, device state or a human pressing something has a modern equivalent. Anything triggered by the arrival of a file does not, and the one mechanism for it lives in Automator, as a Finder feature that applies a workflow to files placed in a chosen folder.

That is the honest scope of this article. Not a defence of Automator in general, but the one job it still holds outright.

The workflow type is the decision, not the actions

The first dialog in Automator asks for a type, and this is where most abandoned attempts go wrong. The actions are interchangeable between types. The type determines what starts the workflow and what it receives, and picking the wrong one means a set of correct actions that never fire.

Apple's guide describes the creation flow as choosing File and then New, selecting the type, reading the description shown in the type menu, and clicking Choose. The description in that menu is the part worth slowing down for, because it states what the type gets handed.

For folder work, the two types that matter are Folder Action and Quick Action. A Folder Action is attached to a specific folder and receives the items placed into it, which suits anything where the arrival is the event. A Quick Action receives whatever is selected, and Apple's guide notes it becomes available from Finder windows, the Services menu and the Quick Actions menu, which suits anything where a person decides which files to process.

The practical division is about who notices. If a person has to remember to run it, the chore has not really been automated, it has been shortened. A Folder Action removes the remembering. That is the whole value, and it is worth choosing the type on that basis rather than on which is easier to build.

Building it, and the shortcut through recording

Once a type is chosen, actions come out of the Library, which Apple's guide describes as grouped into categories by app, file type or data type. Finding the right one is the slow part on a first attempt, and the guide notes three routes: select Library to see everything, select a category to narrow it, or type into the search field. Selecting an action shows its description in the bottom left corner of the window, which is the fastest way to learn what a category contains.

Actions are added by double clicking, reordered by dragging, and the workflow is saved with File and then Save. Each action is handed the output of the one above it, which is why order is not cosmetic.

There is also a route that skips the Library entirely. The guide describes a Record button: click it, perform the task by hand, click Stop, and the recorded action appears in the workflow automatically. This is useful for the steps that have no matching Library action, and it is fragile for the same reason a recorded macro anywhere is fragile, since it depends on the interface staying where it was. A recorded step is best treated as a stopgap inside a workflow that is otherwise built from real actions.

The Quick Action header is the half people skip

For the selection-driven half of folder work, the Quick Action type has a configuration strip across the top of the workflow area, and skipping it produces an action that appears in the wrong places or refuses the files handed to it.

Apple's guide on creating a workflow lists what that strip sets: the type of data used as input, the app the workflow is meant to run inside, the input and output options, and an image and colour for the Quick Action itself. Each of those four has a consequence.

The input data type is the gate. Set it to images and the action is invisible when a PDF is selected, which is usually the intended behaviour and occasionally the reason an action seems to have vanished. The app setting narrows it further, so an action meant for anything selected in a file window should be scoped to the Finder rather than left broad.

The image and colour look decorative and are not, for one reason: Quick Actions surface in a Finder window and in the Quick Actions menu, where several of them end up sitting side by side. Once there are four, the labels are read less than the icons.

The output option is the one that causes silent data loss. An action that replaces its input has no undo path, so the safe pattern for a first version is to write results into a new folder and delete the originals by hand after checking. That costs one manual step per run and buys a recoverable mistake.

The Run Shell Script action, and where point and click ends

Automator's own framing is that scripting is not required:

With Automator, you don't need to know complicated programming or scripting languages to create automations. support.apple.com

That holds for a while, and then a folder chore asks for something no Library action covers, such as a rename rule that depends on the contents of the file. Apple's page on using scripts documents the escape hatch: drag the Run Shell Script action from the Utilities category into the workflow, choose the shell from the pop-up menu, and enter the commands. Run AppleScript and Run JavaScript actions sit in the same category.

Two details on that page are worth carrying away. The shell is chosen explicitly per action, so a script that works in an interactive terminal is not automatically running under the same shell here. And the guide's instruction is to test the workflow before saving it, which is not boilerplate advice for a Folder Action, because a broken Folder Action processes real files without being watched.

Automator is also scriptable from the other direction. The same page notes it can be controlled by AppleScript and JavaScript for Automation commands, including executing workflows and adding actions to them, and that dragging the Automator icon onto Script Editor opens its dictionary. That matters for anyone maintaining several workflows who would rather generate them than click them together.

Reading the Log instead of guessing

A workflow that quietly does nothing is the usual first result, and Automator does report why. Apple's guide on running a workflow describes the Log area, shown with View and then Log, where status messages appear as each action starts and completes. A green checkmark appears on each action as it finishes, so the failure point is visible rather than inferred.

Two more items from that page earn their place in a first build. The View Results action, from the Utilities category, can be dropped between two actions to show what is actually being passed along, which answers the most common failure, where an action receives a different kind of data than expected. And clicking Options at the bottom of an action exposes "Show this action when the workflow runs", which turns a hard coded setting into a prompt at run time.

Debugging a Folder Action has one extra wrinkle. The trigger is a real file arriving, so testing means either putting a file in the folder or running the workflow manually with a test input. Building and proving it as a plain Workflow first, then rebuilding as a Folder Action once the actions are right, avoids doing the proving on files that matter.

Moving a working workflow into Shortcuts

Once a workflow earns its keep, it can be carried across. Apple's import page states that Shortcuts can convert most Automator workflows into shortcuts carrying out the same functions, by dragging a workflow file into Shortcuts, where it appears as a new shortcut.

The word to notice is "most". The conversion covers the actions, and the trigger is a separate question, which returns the discussion to the trigger table above. A Quick Action has somewhere to land in Shortcuts. A Folder Action has no documented equivalent to land in, so converting it produces a shortcut that does the right work and waits to be asked. Anyone importing a set of workflows should expect the folder-triggered ones to need a different arrangement rather than a straight conversion.

The part no workflow reaches

There is a category of folder chore that Automator handles badly, and recognising it saves an afternoon. Automator is strong when the rule is fixed and the work is repetitive: resize everything dropped here, move every PDF into a dated subfolder, strip the same prefix from every name. It is weak when the rule depends on looking at the file, because the looking is the work and no action can do it.

That is the shape of most real filing. A folder of scans needs each one read before it can be named. A folder of downloads needs a judgement about which project each belongs to. A workflow can move those files into a staging folder and stop, and the remaining step is a person opening a preview in one window, a terminal in another, and typing the name by hand. The trigger was never the bottleneck there. The window count was. Features sets out what fits in a single window on that reading, and the FAQ covers what the first week of working that way looks like in practice.

What to change first

Pick the one folder that fills up fastest and write down, in one sentence, what happens to each file that lands in it. If that sentence contains no judgement about the file's contents, build it as a Folder Action today and test it on copies first. If the sentence does contain a judgement, automation is the wrong tool for it, and the thing worth reducing is the number of windows the judgement takes, which is what Atriens was built for.