Automation is easiest to approve when people can see what it will do before it does it. That sounds obvious, but many business workflows move directly from a rule change to live actions: updating customer records, sending notifications, creating tasks, or changing an order status. A small mistake can then be difficult to find because the system has already changed the evidence you needed to investigate it.
A dry run creates a safer review step. Instead of applying side effects, the workflow evaluates its inputs and produces a preview of the actions it would take. The goal is not to pretend that a preview proves everything. The goal is to make assumptions visible, catch bad matches, and give a person or an approval process useful evidence before the live path is enabled.
What a dry run should do
A useful dry run follows the same decision logic as the live workflow, but replaces side effects with recorded intentions. For example, an automation that normally assigns overdue service requests might preview the request ID, proposed owner, reason for the match, and any missing information. It should not actually reassign the requests.
That distinction matters. A test that skips the most important conditions is not a dry run; it is a different program. Keep the input selection, filtering, validation, and branching as close as practical to the live path. Change the final actions: write a record to a review table, generate a report, or return a structured result instead of sending, updating, deleting, or triggering downstream work.
List side effects before writing code
Start by mapping what the workflow can change. The obvious effects may include writing to a database or sending an email, but integrations often have less visible consequences. Creating a ticket can trigger another rule. Updating a CRM field can change a sales queue. Calling an API may create a duplicate record even if your own application does not store anything locally.
For each action, document:
- What system is affected?
- What record or recipient could change?
- What downstream automation could be triggered?
- Can the action be represented as a preview?
- What approval is required before it runs live?
This inventory also reveals where a dry run cannot provide complete safety by itself. An external service may offer a sandbox, test mode, or no-op endpoint; if it does not, use a controlled test account or keep the call out of the preview path entirely. Do not describe a workflow as harmless when it still makes live requests with side effects.
Use representative inputs without exposing unnecessary data
A preview is only useful when its inputs resemble the cases the workflow will handle. A handful of clean examples may confirm the happy path while hiding empty fields, duplicate records, unusual dates, permission differences, and records that belong to more than one category.
Build a small test set from real patterns, but minimize sensitive data. Where possible, use masked or synthetic values that preserve the shape of the data: long names, missing addresses, multiple line items, old timestamps, and conflicting statuses. Keep a record of which scenarios the test set covers and which it does not.
If a sandbox environment is available, use it to isolate development and testing from production. A sandbox reduces risk, but it is not automatically representative. Check the version of the workflow, permissions, connection settings, reference data, and integration behavior before trusting the result.
Make the preview actionable
A dry-run report should help someone decide what to do next. “Completed successfully” is not enough. Include counts and examples such as records evaluated, records that would change, records skipped, validation failures, and external actions that were intentionally suppressed.
For each proposed action, show the before and after values when that is safe, the rule or reason that produced the result, and a stable identifier for the affected record. Separate warnings from errors. A missing optional field may be acceptable; an unknown customer identifier may require the workflow to stop.
Keep the report reviewable after the run. A timestamp, workflow version, input scope, and configuration snapshot make it possible to compare one preview with another. They also create an audit trail for the eventual approval decision.
Test the edge cases that change the decision
Good dry-run coverage is about behavior, not volume. Include cases where no records match, every record matches, one record matches twice, a required field is missing, an external service is unavailable, and an earlier step returns partial data. Test a retry as well. The preview should show whether a retry would repeat an action, skip it, or create a duplicate.
For workflows controlled by feature flags or configuration, test the exact configuration intended for rollout and the fallback configuration. Feature-toggle guidance from Martin Fowler emphasizes testing the combinations that matter and removing temporary toggles after they have served their purpose. A dry run does not eliminate configuration complexity; it gives the team a place to examine it before exposure.
Define approval and rollout gates
Decide in advance what a reviewer must see before the live path is enabled. A simple gate might require zero validation errors, an explanation for every skipped record, and confirmation that the number of proposed changes is within an expected range. More sensitive workflows may need two-person approval or a small first batch.
Roll out in stages when the workflow permits it. Start with a narrow, known input scope, monitor the results, and expand only after the first batch matches the preview. Keep a way to disable the workflow quickly, and document who owns that decision. A rollback plan cannot undo every message or external action, so prevention and limited exposure still matter.
Keep dry-run mode maintainable
Dry-run logic is valuable only while it stays close to the live logic. If the two paths are implemented as separate copies, they will drift. Prefer a shared decision function that produces proposed actions, with one adapter that records those actions for preview and another that applies them after approval.
Review the dry run when the workflow changes. Add a regression case when a production incident or surprising preview exposes a missing condition. Retire temporary test switches and stale reports so operators know which controls are current.
A practical sequence is:
- Map every possible side effect and downstream trigger.
- Define the proposed-action format and the data it must show.
- Create representative, minimized test scenarios.
- Run the same decision logic in preview mode.
- Review errors, skips, counts, and before-and-after values.
- Approve a constrained rollout with monitoring and an owner.
- Compare live results with the approved preview and adjust the workflow if they diverge.
Dry runs are not a substitute for good permissions, backups, monitoring, or careful change control. They are a practical boundary between deciding what an automation should do and allowing it to change business data. For small teams, that boundary can make useful automation easier to review and safer to improve over time.
Next step: Schedule a short consultation to identify the next useful improvement.