Creating test cases
A test case defines, node by node, how a workflow should execute during a test — for real or with mocked values — and what counts as a pass. You can build test cases by hand or auto-generate them with AI; either way they appear in the test case list described in the Automated Testing overview.
Actual vs. mock execution
For each node in the workflow, the test case decides between two execution types:
- Actual — the node runs exactly as it would in the live workflow. Use this for end-to-end testing.
- Mock — the node doesn't really execute; you define dummy input/output values instead. No notifications are sent for a mocked node.
Mock configuration by node type
Each node type has its own mock configuration and its own default execution type:
| Node | Mock configuration | Default |
|---|---|---|
| Manual trigger | Not applicable | Actual |
| Trigger Sync | Not applicable | — |
| Initiator Input | Pick the initiator from the list of bot users; the form is rendered exactly as the end user sees it, and all its validations apply | Mock |
| Action | Set the status (success or failed) and the output (code editor, pre-filled with the current output value of the test run) | Actual |
| Approval | Pick the approver(s) from the list of bot users and set the approval status (Approved or Rejected); the form is rendered as the end user sees it with all validations. | Actual |
| Async callback | Set the status. If failed, choose whether to bypass the timeout (default: No). If success, provide at least one of: Body/Output (code editor, pre-filled with the current output value of the test run), Query string (key/value pairs), Headers (key/value pairs) | Actual |
| Decision | Not applicable | — |
| Delay | Set the delay value | Actual |
| Function | Set the output, pre-filled with the current output value of the test run | Actual |
| Input | Pick the submitting user from the list of bot users; the form is rendered as the end user sees it, and all its validations apply | Actual |
| Synchronous Block | Not applicable | — |
| Update | Not applicable | — |
| Purge | No additional configuration; data is not purged when the node executes as mock | Mock |
| Branch / Merge / Mapper | Not applicable | — |
| End Node (Default) / End Flow (Custom) | Not applicable | — |
Defining success criteria
Success criteria determine whether a test run passes. Three categories are available:
| Category | Description | Default |
|---|---|---|
| Execution status | Multi-select dropdown of expected workflow outcomes: Success, Failed, Withdrawn, Rejected | Success |
| Node execution status | A field array of node + expected status pairs. Statuses: Skipped, Executed with any status, Executed with success status, Executed with failure status, Executed with approved status, Executed with auto-approved status, Executed with rejected status, Cancelled | Blank |
| Custom | A condition builder where you select values from the Data Center, with support for start and end node data | Blank |
Errors in a test case
- If a mandatory mock value is missing, an error is shown on that node.
- If at least one node has an error, the whole test case moves to Error status.
- While a test case is in Error status, each configuration screen shows the errors that belong to that screen, and Save & Continue is blocked — you can keep moving through the configuration and fix errors screen by screen.
Auto-generating test cases with AI
Instead of building every test case by hand, click the auto-generate CTA in the testing section and provide:
- Suggest prompt (text) — Suggests the prompt based on the Workflow.
- Document (file upload) — a BRD, SOW, or similar document, used to check coverage.
After you submit, the generated test cases are added to the test case list for you to validate and to provide mock values where they weren't auto-generated.
Updated about 2 hours ago