Workflow tests

Each workflow has a Tests tab (alongside Editor and Executions). A test case is a saved trigger payload plus a list of assertions checked against the final context once the run completes. Running tests always executes the live draft graph, so you get immediate feedback as you iterate - without manually triggering the real event each time.

Creating a test case

Open a workflow and click the Tests tab. Click New test to open the test form:

1. Name - something you'll recognize: "happy path", "missing email field", "empty array".
2. Trigger payload - a JSON object that stands in for whatever the trigger node would have written into the context. For a Webhook trigger, this replaces the {{webhook.*}} values; for a Form trigger, it replaces {{form.*}}. The payload is seeded directly into the root context the same way initialData is at real trigger time.
3. Assertions - each assertion is a dot-path into the final context, an operator (equals, contains, exists, matches (regex)), and an expected value. A failing assertion doesn't stop subsequent ones from running - you see the full picture in one go.

Running tests

• Run (individual row) - runs that one test case and saves the result to the row.
• Run all - runs every test for the workflow sequentially, capped at 20, and saves each result.

Results are shown inline: pass/fail per assertion, the actual value from the run, a duration, and a link to the full execution detail page. The last result persists on the row so the list always shows the last known outcome at a glance.

Test runs are excluded from the Executions list and from the per-workflow run stats - they don't count against success rate or duration averages.

What to assert

Assertions check the final context after the entire graph runs - not a single node's output. A useful set for a webhook-to-Slack workflow might be:

Dot-path access follows the same convention as Handlebars expressions in node config: httpRequest.httpResponse.data.id, loop.results.0.slack.ok, and so on.

Limitations

• A test payload is a raw JSON stand-in, not a real trigger event - it doesn't simulate trigger-node-specific behavior like Form field coercion.
• A test case that hits a durably-paused node (an Approval or Human Task waiting for a real human response) will time out at 90 seconds. This is expected.
• Run all is fully blocking on the server - for very large test suites, run tests individually if a network timeout is a concern.

Related

• Executions - the full per-node timeline each test result links to.
• Pin / mock node output - the complementary build-time tool for isolating a single node.