A dry run is supposed to make automation safer.

But not every dry run checks the thing that can actually break.

It is common to test the easy part first: load a spreadsheet, parse a report, match rows, calculate totals, and print a preview. That is useful. It tells you whether the source files make sense and whether your local logic is working.

But a real business workflow usually has another boundary: the live system where the final update needs to happen.

That might be a spreadsheet platform, CRM, project management tool, reporting dashboard, email system, ad account, inventory tool, or finance platform. If the automation cannot authenticate, read the destination, verify permissions, or see the expected structure, the local preview is only half a dry run.

The workflow may still be blocked.

Local Success Is Not Workflow Success

Parsing a source file proves one layer.

It does not prove the destination is reachable.

An automation can correctly read every row from a workbook and still fail because an API token expired. It can calculate the right totals and still lack permission to read the live sheet. It can build the right payload and still be pointing at the wrong destination ID.

None of those failures mean the automation logic is bad. They mean the preflight was incomplete.

A stronger dry run checks both sides:

Can the source files be opened and parsed?
Do row counts, totals, dates, and required fields look right?
Can the destination system be reached?
Does the current credential have the required read access?
Does the destination still have the expected tabs, columns, fields, or sections?
Is a live write intentionally disabled until a human approves it?

That last point matters. A dry run should not accidentally become a live run just because the final API call is available.

Permission Checks Should Happen Early

Access problems should be discovered before the operator is ready to ship.

If a weekly report is due, the worst time to learn about an expired token is after the data has already been cleaned, mapped, and queued for update. At that point the team is waiting on an infrastructure problem instead of reviewing the work.

Treat permissions as part of the data pipeline.

The preflight should attempt a low-risk read from the destination before doing anything destructive. It should confirm the destination identity, capture a clear error if access fails, and stop before any write step.

That makes the failure useful:

“Source files parsed, but destination access failed.”
“Token is invalid.”
“Expected sheet or table was not reachable.”
“No live write was attempted.”

That is much better than a vague automation failure after several hidden steps.

Keep The Human Gate Visible

Some workflows should never update live data without approval.

That is especially true for reports people use to make production, shipping, billing, staffing, or customer decisions. Even when the script is reliable, the weekly source files may be wrong, incomplete, or surprising.

The dry run should produce a reviewable summary before the live update:

Which files were used
Which destination was checked
How many rows or records were parsed
Which totals changed
Which assumptions were made
Whether any unmatched rows need a decision
Whether the automation is cleared for live write

This turns approval into a real workflow step instead of a nervous “looks good” before clicking run.

The Takeaway

A dry run should test the workflow boundary, not just the local script.

For business automation, that means checking the source files, the destination system, the active permissions, and the approval gate before changing anything live.

The best preflight does two jobs at once: it proves what is ready, and it clearly explains what is not.

That is how automation becomes easier to trust.