The first action I ever recorded was embarrassing. I was 26, working in a commercial studio in Chicago, and I had just spent three hours manually sharpening and exporting 80 product images one by one. Same settings. Same sequence. Eighty times. When a senior retoucher walked past, glanced at my screen, and said “you know you can record that, right?” I felt equal parts relieved and humiliated. I built my first action that afternoon. Fifteen years later, I track every hour those recordings have saved me. The current total sits at just over 2,400 hours.

Most photographers know actions exist. Far fewer understand what they actually are under the hood, which is exactly why so many actions break the moment conditions change slightly.

What Photoshop Is Actually Recording

When you hit that red button and start recording, Photoshop isn’t capturing a video of your clicks. It’s logging discrete commands in a linear script, each one tied to specific parameters at the time of recording. If you apply Curves and drag the RGB midpoint to an output value of 130, that exact value gets written into the action. If you then run that action on a file with a different color profile or bit depth, the command still fires, but the result can drift significantly.

This matters because most people build actions on a single test file and assume they’ll generalize. They won’t, not reliably. Actions recorded on 8-bit sRGB files behave differently when applied to 16-bit ProPhoto RGB. Sharpening values that look right at 300 PPI will destroy a 72 PPI web export. The action doesn’t adapt. It just executes.

The fix is to build actions with your actual pipeline in mind before you record a single step. Standardize your input conditions first: color space, bit depth, resolution, canvas size. Then record. This is the single most common mistake I see when clients bring me their existing workflow files to audit.

The Mechanics of Conditional Logic and Modal Controls

There are two features inside the Actions panel that most people ignore: modal controls and conditional actions.

Modal controls, toggled by clicking the dialog icon next to any step in the panel, force an action to pause and open a settings dialog before continuing. This sounds counterintuitive for automation, but it’s essential when one step requires human judgment. I use modal pauses on Hue/Saturation adjustments when processing apparel photography, because fabric colors can shift unpredictably between shots and a two-second manual check beats a batch of 200 wrong-colored garments.

Conditional actions, available under the Actions panel menu as “Insert Conditional,” let you branch based on criteria like document orientation, color mode, or whether a layer exists. Say you’re running a batch that includes both landscape and portrait crops. Without a conditional, a fixed canvas resize will ruin one orientation or the other. With a conditional, you route landscape files to one set of steps and portrait files to another. This alone eliminates one of the most common reasons batch processes fail in production.

Building a Batch System That Doesn’t Break at 3am

I run a lot of overnight batches. Files go in before I close my laptop, and I expect finished exports waiting for me in the morning. This only works if the action architecture is solid enough to handle edge cases without crashing the whole queue.

My standard product photography action set runs in this order: open file, flatten, convert to sRGB, apply camera-specific sharpening via a Smart Sharpen step (Amount: 85%, Radius: 0.8px, Reduce Noise: 10%), run a Curves adjustment for monitor-calibrated neutral tones, save a full-resolution TIFF to a “Finals” folder, resize to 2000px on the long edge at 72 PPI, run a second lighter sharpen pass (Amount: 60%, Radius: 0.5px), export as JPEG at quality 9 to a “Web” folder, then close without saving. The whole sequence runs in under 12 seconds per file.

The key to overnight stability is the Error Handling setting in the Batch dialog, specifically “Log Errors to File” rather than stopping on each one. This keeps the batch running if one file is corrupt or oddly formatted, and gives me a log to review in the morning rather than waking up to a frozen queue three files in.

When I Tried to Skip the Groundwork

A few years ago, an e-commerce client came to me in a panic. They had 500 product shots due to a retailer by end of day and their usual retoucher had called in sick. I agreed to process them and decided to use an action set I’d originally built for a different client, a cosmetics brand with a very different background-to-subject contrast ratio. I figured the steps were similar enough.

They weren’t. The skin-tone Curves adjustment that looked perfect on the cosmetics work left the new client’s hardware products with a warm cast that read orange on the retailer’s displays. I caught it after running 40 files. I had to rebuild a corrected action, re-batch those 40, then run the remaining 460, all while the clock ran. We made the deadline, but barely, and I added a line to my action-building checklist that I still use: “Does this action know what it’s being asked to do, or does it just know what it did last time?”

The Difference Between Fragile and Resilient Actions

Fragile actions are built fast, on whatever file happened to be open, with settings dialed in visually rather than technically. They work great on Tuesday’s shoot. They fail on Wednesday’s because the light changed, the background shade shifted, or the client sent files from a different camera body.

Resilient actions are built around input standards, not individual files. They use adjustment layers where possible instead of destructive edits. They include modal pauses at decision points. They log errors instead of stopping. They’ve been tested on at least five different source files before they ever touch a real deliverable.

The 2,400 hours my actions have saved me didn’t come from recording fast. They came from building right the first time, because a broken action running on 500 files doesn’t save time. It manufactures it.