What a dry run should do
A good dry run lets you see exactly what an automation *would* do: which records it would change, what values would be written, and any errors it would hit — all without making those changes in the live system. For small teams the goal is simple: reduce risk with low‑code controls, clear logs and a short human review loop.
Pick tools you already use (HubSpot, Salesforce, Marketo, Pardot or a spreadsheet) and build a visibility-first pipeline: simulate writes, persist the intent, surface exceptions and collect reviewer decisions. Treat the platforms as examples; the operational principle — preview → log → review → measure — works the same everywhere.
Three low‑code dry‑run patterns
- Record‑level staging flag: Add one boolean/property on each record (e.g. automation_dry_run = true) and let workflows build intended changes into staging fields (e.g. next_owner_candidate, staged_invoice_amount, staged_tags). Show a human‑facing list or saved view of records with staged fields and add reviewer properties (review_decision, review_notes, review_at). This works well in HubSpot and Salesforce where custom fields are cheap to add.
- Parallel read‑only pipeline: Run your automation logic into a separate read‑only store — a protected spreadsheet, a lightweight database, or a shadow list in Marketo/Pardot — that mirrors the fields you’d change. The pipeline logs every intended action as a row (record id, intent, error, timestamp). Reviewers tick approve/reject in the sheet; the live system isn’t written to until cutover.
- Canary sampling: Execute the real automation on a tiny, controlled sample (1–5% or a handful of non‑customer test accounts) tagged as canary. Capture every change intent and reviewer decision, but restrict the sample to non‑critical records (test companies, internal users, or synthetic entries). Canary is useful when the full pipeline must be exercised (integrations, billing logic) and you need end‑to‑end confidence.
Each pattern should capture: intent (what would change), error messages, who reviewed it and their decision, and a unique run id so you can group results and compute rates.
From dry run to production: review, measure, rollback and cutover
Run the dry run long enough to get meaningful samples — a week for frequent events, one or two cycles for monthly billing jobs. Use the reviewer decisions to measure false positives (FP rate = rejected intents / total intents) and false negatives (cases the dry run didn’t flag but later caused issues). Track these as simple KPIs on a shared sheet: run id, FP rate, error count, and reviewer comments.
For rollback, keep it simple: snapshot the system (export key records), keep the staging flag or shadow data intact, and make a one‑page rollback plan that says exactly which toggle to flip to stop writes (field flag, workflow off, or integration user disabled) and how to restore from the snapshot if needed. Practice the drill once on a low‑risk automation so the team can execute the plan in 15–30 minutes.
Cutover steps: 1) fix issues uncovered in dry run, 2) run a small canary in production if you used staging or parallel pipelines, 3) enable live writes on a narrow cohort, 4) monitor FP rate and errors for the first 24–72 hours, and 5) fully release when metrics are stable. Keep a one‑line owner for the first 48 hours to respond quickly. If you want practical help designing the right dry‑run pattern for your stack, Optira can run a short workshop and set up the simplest safe pipeline for your team.