Unify Automations › Testing & Deployment › Test Studio › Test Runs
Test Runs
4 mins read
A test run is a single execution of your automation triggered from the testing environment. The Test section of the automation builder records every run it produces, letting you browse past executions, compare results across runs, and drill into the input, output, and error details of any node in any run.
Overview
Every time you start a test, the platform executes your automation against the input you provided and records the full execution trace — what each node received, what it returned, how long it took, and whether it succeeded or errored. This history persists so you can return to any prior run without re-executing the automation. You can compare a failing run to a passing one, track down the node that broke when you changed a field mapping, or verify that a fix produced the expected output before you deploy.
Test page with run history list on the left and the automation canvas with node status indicators in the center
Run History and Results
The test page is divided into three panes that work together. Selecting a run in the left pane loads its execution trace into the center and right panes, letting you inspect every node's behavior for that specific run without re-executing anything.
Run History Pane
The left pane lists every test run recorded for this automation. Each entry shows:
Execution date and time — when the run started.
Total duration — how long the full run took from trigger to final node.
Status tag — the outcome of the run: Successful, Failed, or another platform-defined status.
Click any entry in the list to load its results into the center and right panes. Runs are listed in reverse chronological order — the most recent run appears at the top.
Automation Canvas Pane
The center pane shows the automation as it executed for the selected run. Each node displays a visual status indicator that tells you at a glance whether it succeeded or failed:
Green outline — the node executed successfully.
Red outline — the node encountered an error.
Each node also shows its individual execution time for that run. Click any node in the canvas to open its details in the right pane.
Node Detail Pane
Clicking a node in the canvas loads its execution detail in the right pane. Four tabs are available:
Tab | What it shows |
|---|---|
Input | The raw JSON input the node received from the previous step or trigger. Use this to confirm that the data reaching the node matches what you expected — it is the fastest way to catch a mapping error. |
Output | The data the node returned after executing. This output is what downstream steps received as input. Checking this tab confirms that the node produced the right shape and values before they travel further through the automation. |
Details | Metadata about the execution: the action performed, the connection used, and timing information. Useful when confirming which configured action or connection variant was active for a given run. |
Error | The error message and HTTP status code returned by the external system, if the node failed. This tab is only visible for nodes that errored. Reading the exact status code and message here saves time compared to diagnosing the failure by guessing at the configuration. |
Node detail pane showing the four tabs: Input, Output, Details, and Error
How to Inspect a Test Run
Use this workflow to diagnose a failed run or verify the output of a successful one.
Navigate to the Test tab in the automation builder.
In the Run History pane on the left, locate the run you want to inspect. The status tag — Successful or Failed — identifies failed runs immediately. For failed runs, the most recent entry is usually the right starting point.
Click the run entry to load its execution trace. The canvas in the center updates to show node status indicators for that run.
Scan the canvas for red-outlined nodes. A red outline identifies the node that errored. If multiple nodes are red, the first one in execution order is likely the root cause.
Click the red-outlined node to open its detail. Go to the Error tab to read the exact error message and HTTP status code from the external system.
Switch to the Input tab to confirm what data the node received — a wrong input value often explains the error without needing to examine the node's configuration.
If the run succeeded but produced unexpected data, click the final node or the node you are verifying and open its Output tab to compare the actual values against what you expected.
Repeat the test using Repeat Test (to re-run with the same input) or New Test (to start with different input), then select the new run entry to compare results.
Test run inspection complete — canvas showing green and red node outlines with the Error tab open in the node detail pane
Tip: Click each node in the canvas — not only the last one — even when the run shows an overall Successful status. A failure midway through can sometimes produce a default output that allows later nodes to complete, masking the problem in the run-level status.
Notes
Run history gives you a complete, node-level record of every test execution. Getting the most out of it means knowing where to look and what to look for.
Always read the Error tab on a failed node before reconfiguring the step — the HTTP status code and message often point directly to the cause (wrong credentials, missing field, rate limit) and save time compared to guessing.
Check the Input tab on a failed node before the Error tab when you suspect a mapping issue — confirming that the node received the right data rules out upstream problems before you focus on the node itself.
Use Repeat Test after fixing a node to re-run with exactly the same input and confirm the fix worked in isolation before running a broader test suite.
Compare the Output tab values on key nodes against your expected values — a green node is not a guarantee that its output is correct, only that it did not error.
Use realistic test data that includes edge cases: empty strings, missing optional fields, and boundary values catch more real issues than a test run with only ideal input.
Run at least two tests — one on the happy path and one on a conditional branch or error path — before considering a test session complete.
Run history is persistent but scoped to the current automation. Switching to a different automation clears the visible history — return to the original automation to access its prior runs.