Why Does Every Automation I Build Have a Dry Run Mode?

Why does every automation I build have a dry run mode?

Because the alternative is finding out in production. A dry run makes the automation do everything except write. It reads the real data, applies the real logic, and prints exactly what it would have changed. I have never regretted adding one, and I have regretted every time I skipped it.

This is the single cheapest habit in automation work. It takes an hour to build the first time and about ten minutes on every workflow after that, and it is the difference between a bad deploy costing you a coffee break and a bad deploy costing you a client relationship.

What follows is how I build them, what they catch, and where they stop being enough.

What is a dry run, in plain terms?

A dry run is one flag that turns every write into a description of a write. Instead of creating the record, updating the deal, or sending the email, the automation logs the exact payload it would have sent and where it would have sent it. Nothing downstream changes, and you read the log.

The important word is exact. A dry run that prints a summary is a comfort blanket. A dry run that prints the literal field names and values you were about to push is a review. You want to be able to look at the output and say, that is wrong, before anything acts on it.

In practice the log line for each intended write says four things: the target system, the operation, the record identifier, and the payload. That is enough to catch almost every mistake worth catching.

Why is testing inside your automation tool not the same thing?

Because in most tools a test is a real action. Zapier's own documentation is blunt about it. When you test an action step, Zapier will perform the action on your behalf, and testing is live and may result in changes made in your app. That is not a rehearsal, that is a performance with an audience of one.

Zapier goes further and describes the test record as a representative sample of the step's data when the Zap runs live, and says that for an action step the sample will be data that the step sends to and creates in your app. Read that carefully. The sample is not a preview of a write. It is the write.

Make's own walkthrough for testing a scenario tells you to click the run once button in the scenario builder toolbar, check the output bubbles above each module, and then verify the result by checking your Slack channel. It does not describe a simulation, and the verification step tells you the message actually arrived. n8n, Workato, and the rest all sit somewhere on the same spectrum.

None of this is a criticism of those products. A live test is genuinely useful when you are building a single step against a scratch account. It is the wrong tool when you are about to run a workflow across four hundred records in a client's production CRM.

What should a dry run actually print?

Four things per intended write, and one summary at the end. The target system, the operation, the identifier of the record it would touch, and the full payload. The summary counts writes by type, so you can compare it against what you expected before you read a single line of detail.

The summary line is the part people skip, and it is the part that saves you. If you expected to update about forty contacts and the summary says it would have updated eleven hundred, you have found a filter bug in two seconds without reading anything else.

I also print the things the automation decided not to do, with the reason. Skipped because already synced. Skipped because missing an email address. Skipped because the status did not match. A dry run that only shows the writes hides the most common failure in marketing automation, which is a workflow that quietly does nothing at all.

Where does the switch belong?

At the write boundary, and nowhere else. Every function that touches an external system checks the flag in one place, and every other part of the automation is unaware the flag exists. If you scatter the check through your logic, the dry run stops matching the real run, and a dry run that lies is worse than no dry run.

In practice that means a thin wrapper around each outbound call. One function that creates a Webflow CMS item, one that updates a HubSpot contact, one that appends a row to a Google Sheet, each of them starting with the same check. When the flag is on, they log and return a fake identifier. When it is off, they call the API.

Returning a fake identifier matters more than it sounds. It lets the rest of the workflow keep running so you see the whole chain, including the steps that depend on a record that would have been created. Without it, your dry run stops at the first write and you only ever review step one.

What does a dry run catch that a normal test misses?

Scale and selection. A step test tells you whether one record maps correctly. A dry run tells you how many records the workflow selected, which is where the expensive mistakes live. Wrong filter, wrong date comparison, wrong assumption about what a blank field means.

The automation I run for Ajust moves case data between Airtable and Webflow through WhaleSync, and that pipeline has delivered more than 25,000 cases and helped more than 400,000 people. At that volume, a selection bug is not a bug, it is an incident. The dry run output is the only thing standing between a filter typo and four thousand wrong records.

The second thing it catches is the destructive edge. A workflow that updates a field is fine. A workflow that updates a field to an empty string because the source was null is a data loss event, and it reads identically in a step test. In a dry run it is obvious, because you are looking at the payload and the payload says the field is empty. I wrote separately about what an automation should never be allowed to do, and blanking a populated field is high on that list.

When is a dry run not enough?

When the failure you are worried about happens inside the other system. A dry run proves your logic is right. It cannot prove that the destination will accept the payload, that a required field exists, or that a rate limit will not stop you. For that you need a real write somewhere a mistake does not matter.

So the sequence I use is dry run first, then a real run against a sandbox or a test account, then a real run limited to five records in production, then the full run. Each stage answers a different question, and skipping the sandbox stage is where most people get hurt, because that is the stage that surfaces schema mismatches.

The HubSpot automation I run for Kismet Health through Zapier lives in this category. The logic is simple. The risk is entirely about what the CRM does with the record once it arrives, which no amount of local reasoning will tell you. I have a companion piece on building a rollback plan for an automation that writes to your CRM, because the stage after the dry run is the stage where you need one.

How do you stop the dry run from rotting?

By running it on a schedule, not only before a deploy. A dry run that nobody has executed in three months is documentation, not a safety net, and it will have drifted from the live path the first time someone adds a step without the wrapper.

My rule is that the dry run executes automatically once a week against real current data, and the output lands somewhere a human will see it, usually a Slack channel or an Airtable log. Nobody reads it carefully every week. That is fine. The point is that it fails loudly when it breaks, so the safety net is known to work on the day you need it.

I also keep the dry run flag in version control with the rest of the automation, in Git, so a change to the wrapper shows up in a diff. When someone asks why a write was not caught, the answer should be a commit, not a memory. If you are working with AI agents in the loop, the same discipline applies, which is the argument I made in testing an AI automation before it touches real customer data.

What should you do next?

Pick the automation you would least like to explain to a client, and give it a dry run this week. Wrap every outbound call in one function, add a flag, print the target, the operation, the identifier, and the payload, and add a summary count at the end. An afternoon of work, at most.

Then run it against today's real data and read the summary line. In my experience you will find something on the first attempt, usually a selection that is wider or narrower than you assumed. That one finding pays for the whole exercise.

I have been building automations for clients for six years, and the ones I sleep well about are not the sophisticated ones. They are the ones that can tell me what they are about to do before they do it. If you have a workflow running unattended and you are not sure what it would say, reach out. Let's chat about it.