Test Safely Before Going Live

Before you enable a schedule or trigger, you need confidence that your assignment behaves correctly — and that a bad Job cannot cause irreversible damage. This guide gives you a concrete test plan, patterns for isolating side effects, and strategies for keeping test and production environments separate. This is the testing half of the journey to production. Once testing is signed off, use Promote to Production to enable your schedule or trigger and hand the assignment to your team.

Test Plan Template

Copy this template for each assignment you are preparing for production. Work through every section before enabling autonomous Jobs.

Assignment: [Name]
Builder: [Name]
Test date: [Date]

HAPPY PATH
[ ] Ran with realistic production-like input
[ ] Output is correct and complete
[ ] Job finished within expected duration

EDGE CASES
[ ] Missing or empty input fields — assignment handles gracefully (logs, skips, or escalates)
[ ] Unexpected data format (e.g., date as text, wrong currency symbol) — no crash
[ ] Duplicate input — idempotency check prevents duplicate actions

FAILURE INJECTION
[ ] Connection Login revoked mid-Job — assignment fails cleanly without partial writes
[ ] Rate limit or timeout from an external system — assignment retries or escalates appropriately
[ ] Required field absent in source data — assignment stops and surfaces the gap rather than guessing

HUMAN-IN-THE-LOOP COVERAGE
[ ] Every HITL approval branch has been triggered at least once
[ ] Approval request denied — assignment handles denial gracefully (stops, logs, does not retry automatically)
[ ] HITL request left unanswered past the configured window — escalation fires

COST AND DURATION
[ ] Estimated cost per Job is within budget
[ ] Typical Job duration fits within the business process SLA

DATA IMPACT
[ ] All writes verified to have landed in the correct records / accounts
[ ] No duplicate records created
[ ] No unintended recipients received emails or notifications

How to Mock Dangerous Side Effects

The goal during testing is to observe what the assignment would do without allowing it to write to live systems. Use the patterns below for the connections your assignment touches.

Read-only mode via SOP instruction

Add a shadow-mode block at the top of the SOP before running test Jobs. Remove it only after you are satisfied with the outputs.

SHADOW MODE — DO NOT WRITE:
Read all data and log what actions you would have taken, but do not
submit, send, update, or delete anything. Summarize at the end:
"Would have [action] for [count] records."

See Guardrails for High-Risk Automations for the full shadow-mode pattern.

Per-connection safe testing

Connection	Safe testing approach
Gmail / Outlook	Send emails to your own address or a team test alias instead of real recipients. Add the target override to the SOP: “Send all emails to test@yourcompany.com during testing.”
Google Sheets / Excel	Point the assignment at a copy of the production spreadsheet, not the live one. Rename it clearly: `[COPY — TEST ONLY] Monthly Sales`.
Snowflake / BigQuery	Use a read-only Login during testing. Grant write access only after output verification.
Slack	Post to a private test channel (e.g., `#assignment-testing`) instead of customer-facing channels. Update the SOP with the channel name before testing.
HubSpot / Salesforce / CRM	Use a sandbox or developer instance if your plan includes one. If not, add a test-contact filter: “Only update records tagged `TEST` during testing.”
Database writes	Create a staging schema or table prefixed with `test_`. Point the assignment at it during testing.

Inspecting proposed actions before they land

Some assignment types can log their intended actions before executing. Add this instruction to the SOP when you want to review a batch before committing:

Before performing any write operations, list every action you intend to take.
Pause and request approval:
Title: "Pre-flight review — [count] actions pending"
Description: List each action with the target record and the proposed change.
Only proceed after the review is approved.

Environment Separation Patterns

These are the three approaches teams use most often to keep test traffic separate from production systems.

Pattern 1 — Two builds, one SOP

Create a second build of the assignment by duplicating it. Name the copy clearly (e.g., [TEST] Invoice Processor).

The test build uses sandbox accounts, test spreadsheets, and a test Slack channel.
The production build uses production credentials and live targets.
When the SOP changes, update both builds. Promote the change to the production build only after the test build confirms it.

This is the lowest-friction pattern for most teams. See Duplicating Assignments for how to duplicate a build.

Pattern 2 — Two teams, one SOP

Some teams run a dedicated sandbox Duvo team (or workspace) alongside the production team.

The sandbox team holds test connections and test data sources.
Builders develop and test in the sandbox team, then recreate the assignment in the production team.
Connections in the production team are scoped to live accounts.

This pattern provides the strongest isolation and is common in organizations with strict change-control requirements.

Pattern 3 — Connections scoped per environment

Use a single build but maintain two connection profiles: one for testing and one for production. Before a test run, switch the assignment to use the sandbox connections. After testing, switch back. This approach requires discipline to avoid accidentally running with the wrong connections. Reserve it for simple assignments where the risk of a mistaken production write is low.

Using Assignment Versions for Safe Iteration

Every time you save a change to your assignment, Duvo creates a new revision. Use revisions to iterate safely during testing without losing working configurations.

When to create a new revision vs edit in place

Create a meaningful revision when you make a change that materially affects behavior — new HITL gate, updated output format, different connection target. Small wording tweaks to a SOP that is already working can be saved in place.

Testing a change before making it live

Open the assignment and make your changes.
Save. Duvo creates a new revision.
Run a test Job using the new revision to verify behavior.
If the test Job fails, revert to the previous revision immediately — do not leave a broken revision as live while you investigate.

Reverting to a previous revision

Open the assignment.
Click the revision selector in the builder toolbar.
Select the last known-good revision.
The assignment now uses the reverted SOP for the next manual run, scheduled run, or trigger.

Note: Scheduled Jobs and triggers always execute the live revision, not the one you are currently viewing. A warning banner appears at the top of the builder whenever you are viewing a non-live revision.

See Assignment Versions for the full versioning reference.

Pre-Production Checklist

Work through this list when testing is complete and you are ready to go live. If any item is not checked, address it before enabling the schedule or trigger.

TESTING SIGNED OFF
[ ] Test plan completed — all sections checked
[ ] At least three end-to-end test Jobs have run without unexpected failures
[ ] HITL branches exercised: approval granted, approval denied, escalation triggered
[ ] Edge cases identified during testing are handled in the SOP or accepted as known gaps

ENVIRONMENT READY
[ ] Assignment points to production connections, not sandbox or personal accounts
[ ] Production connections are scoped to the minimum permissions required
[ ] Logins and Secrets belong to a service account or shared Login, not a personal account
[ ] Shadow-mode instruction removed from the SOP

RISK CONTROLS IN PLACE
[ ] Every irreversible or externally visible action has a HITL approval gate
[ ] Hard caps on action volume or spend are set in the SOP
[ ] Idempotency checks prevent duplicate actions on retry

TEAM READY
[ ] Runbook complete — owner, backup contact, failure response, pause procedure
[ ] Operators know how to find Jobs and respond to HITL requests
[ ] Rollback path tested — previous working revision identified

Ready to go? Continue with Promote to Production.

Promote to Production — Enable your schedule or trigger and hand the assignment to your team
Guardrails for High-Risk Automations — Risk scoring, shadow mode, and hard caps for high-stakes assignments
Assignment Versions — How versioning works and how to revert a change
Designing Human-in-the-Loop Workflows — When to add approval gates and how to configure escalation
Duplicating Assignments — How to create a test build alongside your production build

Documentation Index

​Test Plan Template

​How to Mock Dangerous Side Effects

​Read-only mode via SOP instruction

​Per-connection safe testing

​Inspecting proposed actions before they land

​Environment Separation Patterns

​Pattern 1 — Two builds, one SOP

​Pattern 2 — Two teams, one SOP

​Pattern 3 — Connections scoped per environment

​Using Assignment Versions for Safe Iteration

​When to create a new revision vs edit in place

​Testing a change before making it live

​Reverting to a previous revision

​Pre-Production Checklist

​Related