Test Mode

Test mode lets you run an automation without touching real external systems. Instead of executing every step for real, steps with pinned data return pre-recorded output. This means you can test workflow logic, conditions, and data flow without side effects.

Why Test Mode

Building automations often involves steps that are slow, expensive, or have real consequences. Sending emails, updating databases, calling paid APIs, or modifying production records are all things you want to avoid while you are still developing and debugging.

Test mode solves this by letting you freeze the output of steps you have already verified and only run the parts you are actively working on.

Problem	How test mode helps
Expensive API calls	Pin the output and skip the real call
Slow database queries	Use cached results instead of waiting
Destructive operations	Avoid sending real emails or updating records
Unstable external systems	Remove dependency on systems that may be down
Iterating on later steps	Skip earlier steps that already work correctly

The Basic Idea

Run Once for Real

Execute the job normally to capture real output from each step

Pin Step Data

Save the output of steps you want to mock in future runs

Enable Test Mode

Turn on test mode for the job

Run with Mock Data

Pinned steps return saved data, unpinned steps execute normally

Simple: capture real output once, then reuse it as mock data while you work on other parts of the automation.

How to Enable Test Mode

Test mode is toggled per job from the Canvas.

1. Open the job's Canvas
2. Click the Enable Test Mode toggle in the Canvas toolbar
3. The toggle now reads Disable Test Mode — the job uses pinned data where available

Click Disable Test Mode to return to normal execution.

When test mode is enabled, all future runs of that job use pinned data where available. The job itself is not changed in any other way.

Advanced: toggle via the API

You can also flip test mode programmatically instead of using the Canvas toggle:

POST /jobs/:id/test-mode?enabled=true

To disable test mode and return to normal execution:

POST /jobs/:id/test-mode?enabled=false

Pinning Step Data

Pinned data is a snapshot of what a step returned during a real execution. When you pin a step, you are telling Automation Hub: "Use this output instead of running the step for real."

What Gets Pinned

Each step can store pinned data in whatever format the step normally produces. This can be JSON objects, arrays, plain text, or any other output the step returns. The pinned data replaces the entire step output during test mode runs.

How to Pin

1. Open the step in the builder
2. Click Execute Step (or run the whole job once) so the step produces real output
3. In the step's Output pane, review the result to make sure it looks correct
4. Click Pin output — a toast confirms "Output pinned successfully!"

Pinning sets pinEnabled to true on the step and stores the output as pinnedData, so the step returns this snapshot during test-mode runs. To remove the pin, click the button again (you will see "Output unpinned."). You can also click Edit output to adjust the pinned data by hand before saving it.

You can pin as many or as few steps as you need. Each step is independent.

How Pinned Data Works During Execution

When a job runs in test mode, each step is checked before execution:

• If pinEnabled is true and test mode is active, the step skips plugin execution and returns its pinnedData instead
• The pinnedDataUsed flag is set on the StepExecution record so you can tell which steps used mock data
• If pinEnabled is false or the step has no pinned data, the step runs normally

Running in Test Mode

Once you have pinned the steps you want to mock and enabled test mode, simply run the job as usual. The execution works the same way it always does, but pinned steps are short-circuited.

Step 1: Query DB

Pinned

Returns saved query results instantly

Step 2: Transform

Pinned

Returns saved transformation output

Step 3: Send Report

Runs for real (not pinned)

In this example, only step 3 actually executes. Steps 1 and 2 return their pinned data.

After the run completes, you can check each step execution to see whether it used pinned data by looking at the pinnedDataUsed flag.

Mixing Pinned and Live Steps

You do not need to pin every step. Test mode gives you full control over which steps use mock data and which ones run for real.

This is especially useful when:

• You are adding a new step at the end of a workflow and the earlier steps are expensive
• You want to test a conditional branch without waiting for upstream steps
• You need to debug a specific step while keeping the rest stable

Example: Testing a new notification step

Fetch Orders

Pinned

Takes 30 seconds normally, returns instantly with pinned data

Filter Large Orders

Pinned

Returns saved filter results

Send Slack Alert

New step, runs for real so you can verify it works

Pin the slow upstream steps and only execute the step you are actively developing.

Unpinned steps receive real input from the previous step. If the previous step was pinned, the unpinned step receives the pinned data as its input. This means the data flow through the automation works exactly the same as a real run.

When to Use Test Mode

Scenario	Test mode approach
Building a new automation	Run once to capture data, then pin early steps while you build later ones
Debugging a failing step	Pin all steps before the failing one so you can iterate quickly
Testing conditional logic	Pin steps with specific data that triggers the condition you want to test
Developing without network access	Pin all external steps and work offline
Avoiding rate limits during development	Pin API call steps to avoid hitting the external service repeatedly
Validating data transformations	Pin the input step and focus on the transformation logic
Demonstrating an automation	Pin all steps for a fast, predictable demo run

Tips for Better Testing

Capture realistic data. Run the job against real systems at least once to get accurate pinned data. Made-up test data may not cover edge cases like empty arrays, null fields, or unexpected formats.

Update pinned data when schemas change. If an external system changes its response format, your pinned data becomes outdated. Re-run the step for real periodically to keep pinned data fresh.

Pin at natural boundaries. Pin steps that talk to external systems (API calls, database queries, email sends) and leave data transformation steps unpinned. This tests your logic while skipping external dependencies.

Check the pinnedDataUsed flag. After a test mode run, review the execution to confirm that the right steps used pinned data. If a step you expected to be pinned ran for real, check that pinEnabled is set correctly on that step.

Remove pins before production. When you are done developing, disable test mode and unpin all steps. Leaving test mode enabled on a production job means real data will not be processed.

Test with different pinned data sets. You can update the pinned data on a step to simulate different scenarios, like empty results, error responses, or large data sets. This helps you verify that your automation handles edge cases correctly.