Every time I open a client’s Photoshop file and find a dozen unnamed brushes with opacity set to 37% and hardness at some arbitrary middle value, I feel it in my chest. Not judgment, exactly. More like recognition. That was me, fifteen years ago, before I understood that a brush isn’t just a painting tool. Inside an automated workflow, it’s a variable. And variables you don’t control will eventually wreck a batch run at the worst possible time.

If you build actions, run batch processes, or share presets with other people, the way you construct your brushes matters as much as the actions themselves.

Why Brush Settings Are Not Just Aesthetic Choices

Photoshop records brush behavior into actions at a surprisingly shallow level. When you record a paint stroke inside an action, Photoshop logs the tool, the blend mode, the opacity, and the flow. What it doesn’t reliably lock down is the source brush tip itself, especially if that tip lives in a set that isn’t loaded on the receiving machine.

This is the root of most brush-related action failures. You build an action on your workstation with a custom tip you made in 2019, share it with a colleague or sell it through a preset pack, and on their machine the action either defaults to the standard round brush or throws an error. The automation breaks not because your logic was wrong but because the asset it depended on wasn’t there.

The fix isn’t complicated, but it requires building brushes with portability in mind from the start.

The Anatomy of a Portable Brush Preset

When I build a brush for use inside an action, I start from a captured brush tip rather than a procedural shape. Go to Filter > Convert for Smart Filters first if you’re working on a pixel layer, then paint or place whatever mark you want, select it with a rectangular marquee, and choose Edit > Define Brush Preset. Give it an explicit name that includes its intended use, something like “SoftDodge_Feather80_v2” rather than “Brush 14.”

The settings I lock in before recording any action that uses the brush:

  • Size: Set to an absolute pixel value relevant to your typical document resolution. I work mostly at 3000 x 3000 pixels at 300 PPI for product shots, so my standard retouching brushes are between 200 and 800 pixels.
  • Hardness: Either 0% or 100%. Anything in between introduces ambiguity when the brush scales. I use soft brushes for dodging and burning, hard brushes for masking and cutout work, and I keep them in separate named sets.
  • Opacity and Flow: Set these in the options bar before recording the action step, not inside the Brush Settings panel. The options bar values are what get written to the action record.
  • Spacing: Default is 25%. For texture brushes I drop this to 1-5% so strokes read as continuous marks rather than repeated stamps. For stamp-style brushes I push it to 100% or higher.

Once the settings are dialed, export the brush as a .abr file immediately. This is your source of truth. The brush exists in that file, and that file should live in the same folder as any action or preset that depends on it.

Building the Action Around a Specific Brush State

Here’s where most tutorials skip a critical step. Before you hit the record button in the Actions panel, load the exact brush preset you intend to use and set every parameter manually. Then start recording.

Photoshop will write the brush name and the options bar settings into the action step. When the action runs, it calls that brush by name. If the brush preset is loaded, it works. If it isn’t loaded, Photoshop falls back on whatever was last active, and your carefully constructed technique produces garbage output.

The workflow I use for any action that involves a brush stroke:

  1. Save the .abr file into the action’s distribution folder.
  2. Add a “Stop” step at the beginning of the action with instructions telling the user to load the .abr file first.
  3. After the stop, add a manual “Load Brushes” reminder or, if you’re comfortable with scripting, use a Script step that auto-loads the preset from a relative path.

That stop message takes thirty seconds to write and has saved me hundreds of support emails over the years.

The Time I Skipped This and Paid for It

A few years into running my own consultancy, I built a batch system for a skincare e-commerce client, around 500 SKUs, processed across two days. The retouching action included a frequency separation step that used a custom healing brush with specific texture settings. I had built and tested the whole thing on my main workstation.

When I moved the job to my secondary machine to speed up the batch, I forgot to transfer the brush preset. The action ran. All 500 files got processed. None of the texture healing looked right because the fallback brush had hardness at 50% and spacing at 25% instead of my 0% hardness, 5% spacing setup. I had to rerun the entire batch. That cost me about four hours, which, yes, I logged in my tracking spreadsheet. It remains one of the more expensive lessons in my Photoshop life.

Naming Conventions and File Organization That Keep You Sane

I keep all custom brushes in a folder called “Brush_Assets” inside each project’s preset kit. File names follow this pattern: [UseCase][Hardness][SizeRange]_[Version].abr. So: “TextureHealing_Soft_400-800_v3.abr”. This reads clearly whether you’re looking at it in six months or handing it to a client.

I also keep a plain text file in that same folder listing which actions depend on which brush files. It’s a two-minute task that has prevented a disproportionate number of production failures.

Custom brush creation is a craft skill, but making those brushes reliable inside automated workflows is an engineering problem. Solve the engineering side first and the creative side will have a stable foundation to stand on.