Testing runs a single instance of your automation with predefined input data so you can inspect the output of every node before the automation goes live.

Overview

Testing runs a single instance of your automation with predefined input data so you can inspect the output of every node before the automation goes live.

The Test section of the automation builder lets you execute your automation with hard-coded input — mimicking a trigger payload — and then inspect what each node received, returned, and (if applicable) errored on. Tests are isolated from live data and do not affect production records.

Before a test runs, the automation is validated. If there are problems, you will see a Please fix errors message — "Your workflow contains errors that need to be fixed before testing can proceed" — and the run is blocked until the errors are resolved.

How to Test Your Automation

• Navigate to the Test tab in the automation builder.

• Click Run to start a new test. The New Test dialog opens with the prompt: "Provide sample trigger data to test this automation."

• Select how to provide trigger data using Provide trigger data using — choose Form (a form built from the trigger's schema) or JSON (a raw payload).

• Click Run Test to execute the automation. If the trigger needs no input, the test starts immediately.

• While the test runs, you will see Testing your automation. Please wait... — you can click Stop to cancel an in-progress test at any time.

• Click Repeat Test to re-run the test with the same input data.

• Click New Test to start a fresh test with different input data.

Note: A test run can execute for a maximum of 20 seconds only. If the execution time exceeds this limit, the test run is automatically cancelled.

Note: If the automation has no setup schema defined, clicking "Run Test" executes it without input.

Test Run Results

A finished test shows the automation as a canvas you can walk through. The results header displays the execution date (Executed On {date}), a duration pill, and a status pill indicating the outcome:

Click any step to view its details. Each step shows timing information — This step took {time} to execute, This step was cached & took {time} to execute (for cached steps), Retry #1 (for retried steps), or This step was not executed. Use Copy step inputs and Copy step outputs to copy step data for debugging or sharing.

The Test Page

The test page is divided into three panes:

• Left — Run History: Lists every test that has been run for this automation. Each entry shows the execution date and time, the total duration, and a status tag (Successful, Failed, and so on). Click any entry to load its results in the center and right panes.

• Center — Automation Canvas: Shows the automation as it executed for the selected test run. Each node displays its execution time and a visual status indicator:

• Green outline — node passed successfully

• Red outline — node errored

• Right — Node Detail: Click any node in the center pane to open its detail view:

• Input tab — the raw JSON input the node received

• Output tab — the data the node returned, available as data pills to downstream nodes

• Details tab — metadata about the execution (action, connection, timing)

• Error tab — the error message and HTTP code if the node failed (visible only on failed nodes)

Test Step

To trial a single step on its own without running the full automation, open Test Step on any step in the canvas. The Test Step panel provides two tabs:

• Test tab — Run the step in isolation with the specified input parameters.

• Unit Test tab — Configure a focused unit test for the step.

Enter values in Input Parameters and Test Input, then run the step. The Test Result shows either Successful with a Status Code, or Test failed ("Failed to execute request. See details below."). Failed steps offer Debug with AI and Fix this error helpers to assist with troubleshooting.

Debugger

The Test tab includes a step-through debugger for inspecting your automation one step at a time. Set breakpoints on individual steps using Add Breakpoint, and remove them with Remove Breakpoint. Once breakpoints are set, drive the run using the following controls:

• Continue — Resume execution until the next breakpoint or the end of the automation.

• Step Over — Execute the current step and pause at the next one.

• Step Into — Step into a nested automation or sub-flow.

• Step Out — Step out of the current nested context.

• Restart — Restart the test run from the beginning.

You can Disable all breakpoints, Enable all breakpoints, or Remove all Breakpoints at once. A run that used breakpoints is tagged as a Debug run in the test history, and you can pick up where you left off with Continue Debugging.

Note: Breakpoints cannot be added or removed while a run is executing.

Test History

The Test History panel on the Test tab lists all previous tests under a Previous Tests heading. Each entry shows its date, status pill, and Time taken. A New Test card at the top of the panel starts a fresh test, and See all Runs opens the full list. If you have not run any tests yet, the panel shows No Previous Tests Found ("You can start a new test").

Use Repeat Test to re-run the last test with the same data, or New Test to start fresh with different input.

Notes

Testing before deploying prevents the most common class of issues: misconfigured inputs, missing connections, and incorrect field mappings. To test effectively:

• Use realistic test data that covers edge cases — a test with empty strings, missing optional fields, and large numbers catches more bugs than a test with ideal values.

• Click each node in the center pane, not just the last one — a failure midway through may show a successful final state if later nodes have default outputs.

• Use the Error tab to read the exact HTTP status code and message returned by the external API; it saves time compared to re-configuring the node based on a guess.

• Run at least two tests — one "happy path" and one with data that should trigger a conditional branch or error path.

• Use Test Step to isolate and debug individual steps that fail, taking advantage of the Debug with AI and Fix this error helpers for faster troubleshooting.

• Set breakpoints with the debugger to walk through complex automations step by step, especially when investigating unexpected behavior in branching logic.

A test that passes every node with green is not a complete validation; also check that the Output tab values on key nodes match what you expect.