An execution is one workflow run. To verify an automation, check both the final status and the expected result: the correct destination, created fields and absence of unwanted effects.
Read the status
pending: the execution is waiting for processing.
running: processing is in progress.
paused: processing is waiting to resume, for example after a wait or approval request.
success: the execution finished without a technical failure reported to the engine.
failed: an error caused the execution to fail.
cancelled: the execution was cancelled.
success alone does not guarantee the business result. An IF may have taken an unexpected branch, and an HTTP node can be configured to accept error statuses. Check outputs and the actual destination.
Test a step
An isolated test examines a configuration. A chain execution also checks upstream data preparation. A complete run checks branches and overall behavior.
After changing mapping, run the steps that produce data again, then the consumer. Verify:
Received input matches the test case.
Output contains the expected field and type.
The next node’s expressions read this actual output.
The test destination contains the expected result if an external action occurred.
A test can send a message or modify data when you run a real action. Use test access and destinations for these checks.
Read an error
Start with the first failed node in execution order. Record its exact message, then compare its configuration and received data. Subsequent steps that did not run are often a consequence of this failure.
For an integration, next check the credential, resource permissions and service response. For an empty expression, check structure and technical names before changing the service being called. Troubleshooting by symptom helps select the right check.
Retries and fallback workflows
Workflow settings can stop, retry the complete workflow or failed node, or start another published workflow belonging to the same owner. Node retries are exhausted before the global policy. Node tests and partial executions ignore this policy.
Choose the scope based on effects already produced:
Failed node: avoids deliberately replaying the entire chain, but the service may have performed the action before its response was lost.
Complete workflow: also replays previous steps, including successful writes.
Fallback workflow: can notify or handle the incident without making the original execution successful.
The fallback workflow receives the failed execution in input.payload.execution and caller information in input.source. It starts without waiting for completion; the original execution remains failed.
Agent tool approval
A tool with requireApproval: true pauses the workflow. In history, an authorized person reviews the action and arguments, then chooses Approve and resume or Reject and resume. Rejection is passed to the model without executing the rejected action. Resuming restores messages and completed tools, including after a restart.
Each protected call needs its own decision. This pause requires a complete workflow, outside loops, inline calls or nested agents. To answer an approval, resume the relevant execution instead of starting a new complete run.
External triggers
After publishing, generate a real event and find its execution using the time, trigger type and a test identifier in the data. Check completion and the result in the destination service.
A test with a simulated payload only validates processing for that example. It does not check networking, incoming authentication, event subscriptions or scheduling. A webhook using immediate response mode can also reply before the workflow finishes.
History retention
Plans define execution retention and detail entitlements. Check Pricing and licenses and your active plan for applicable values. For support, record necessary information while it is available, removing secrets and personal data.
An execution is one workflow run. To verify an automation, check both the final status and the expected result: the correct destination, created fields and absence of unwanted effects.
Read the status
pending: the execution is waiting for processing.running: processing is in progress.paused: processing is waiting to resume, for example after a wait or approval request.success: the execution finished without a technical failure reported to the engine.failed: an error caused the execution to fail.cancelled: the execution was cancelled.successalone does not guarantee the business result. An IF may have taken an unexpected branch, and an HTTP node can be configured to accept error statuses. Check outputs and the actual destination.Test a step
An isolated test examines a configuration. A chain execution also checks upstream data preparation. A complete run checks branches and overall behavior.
After changing mapping, run the steps that produce data again, then the consumer. Verify:
A test can send a message or modify data when you run a real action. Use test access and destinations for these checks.
Read an error
Start with the first failed node in execution order. Record its exact message, then compare its configuration and received data. Subsequent steps that did not run are often a consequence of this failure.
For an integration, next check the credential, resource permissions and service response. For an empty expression, check structure and technical names before changing the service being called. Troubleshooting by symptom helps select the right check.
Retries and fallback workflows
Workflow settings can stop, retry the complete workflow or failed node, or start another published workflow belonging to the same owner. Node retries are exhausted before the global policy. Node tests and partial executions ignore this policy.
Choose the scope based on effects already produced:
The fallback workflow receives the failed execution in
input.payload.executionand caller information ininput.source. It starts without waiting for completion; the original execution remains failed.Agent tool approval
A tool with
requireApproval: truepauses the workflow. In history, an authorized person reviews the action and arguments, then chooses Approve and resume or Reject and resume. Rejection is passed to the model without executing the rejected action. Resuming restores messages and completed tools, including after a restart.Each protected call needs its own decision. This pause requires a complete workflow, outside loops, inline calls or nested agents. To answer an approval, resume the relevant execution instead of starting a new complete run.
External triggers
After publishing, generate a real event and find its execution using the time, trigger type and a test identifier in the data. Check completion and the result in the destination service.
A test with a simulated payload only validates processing for that example. It does not check networking, incoming authentication, event subscriptions or scheduling. A webhook using immediate response mode can also reply before the workflow finishes.
History retention
Plans define execution retention and detail entitlements. Check Pricing and licenses and your active plan for applicable values. For support, record necessary information while it is available, removing secrets and personal data.