Test a Workflow or API
Use tests to confirm that a deployed workflow accepts the expected input, returns a useful response, and behaves correctly with realistic data. A saved test case gives the team a repeatable check for future changes.
Before you begin
- Deploy or promote the workflow version you want to test.
- Confirm which environment is safe for the test data.
- Prepare representative input, including a successful case and likely failure cases.
- Make sure you have permission to view and update tests in the workspace.
Use safe test data Do not submit production credentials, personal data, or records that can trigger an irreversible business action unless the environment and workflow are intended for that test.
Choose the right test
| What you need to verify | Test mode |
|---|---|
| A request-and-response workflow or REST endpoint | HTTP |
| A SOAP operation | SOAP |
| An event received at a webhook | Webhook |
| A message sent to a configured channel | Queue |
The available modes depend on the selected workflow and its deployment configuration.
Run a test
- Open Test, or select Test from the deployed workflow.
- Select the environment and test mode.
- Enter the request details required by the workflow. Depending on the mode, this can include a URL, method, headers, parameters, body, message properties, or channel.
- For a secured workflow, select Refresh Token before sending the request.
- Review every dynamic value and confirm that the target environment is correct.
- Select Send or Test Webhook.
The result area updates while the test runs. Review the status, elapsed time, headers, response body, and any returned message details before deciding whether the test passed.
Evaluate the result
Do not treat a successful status alone as proof that the workflow is correct. Check that:
- the response represents the expected business outcome;
- required fields are present and correctly formatted;
- no sensitive values appear in the response;
- an invalid request returns a useful, controlled error;
- repeated requests do not create unintended duplicate work;
- downstream changes occurred only in the intended environment.
If the result is unexpected, use metrics and traces to follow the execution and identify the failing step.
Save a reusable test case
- Give the test a name that states the scenario and expected outcome, such as
Create employee - valid request. - Select Save.
- When a matching test case already exists, save the input as an Example instead of creating a duplicate.
- Keep one example for the normal path and separate examples for important boundary or error cases.
Saved test cases should contain stable sample values. Replace short-lived tokens and environment-specific identifiers before another user runs the test.
Use examples and history
- Examples preserve useful variations of a test case without duplicating its purpose.
- History lets you reopen a previous execution and compare its request and result with the current behavior.
- A history entry is evidence from one run, not a permanent acceptance record. Keep formal release evidence in your team's approved system of record.
Troubleshoot a test
| Problem | What to check |
|---|---|
| Send is unavailable | Complete the required URL, channel, body, or variables for the selected mode. |
| The request is unauthorized | Refresh the token, confirm the environment, and check the workflow's security setting. |
| The result is empty | Confirm that the workflow returns a response and inspect its trace. |
| The result differs between environments | Compare deployment profiles, variables, resources, and schemas. |
| A saved test cannot run | Confirm that its application, workflow, and deployed version still exist. |
Next steps
After the tests pass, record the scenarios used, review the deployment configuration, and continue with the team's release or promotion process.