Operating Workflows
Operating Workflows answers: How do I test a workflow, take it Live, and run it safely over time? Use it for the operating loop; use the focused pages below for run evidence, failure behavior, versions, or a specific symptom.
Choose the right operational page
| Question | Go to |
|---|---|
| What happened across workflows in this workspace? | Activity |
| What happened in one workflow’s run? | Execution Log |
| What entered and left one Step? | Step-Level Executions |
| How do retries and error routes work? | Error Handling & Retries |
| How do Draft, Live, and saved versions relate? | Versioning |
| What does this symptom or error message mean? | Troubleshooting & Common Errors |
The operating loop
| Stage | Decision to make | Use |
|---|---|---|
| Test | Does the workflow follow the intended path with realistic data? | Testing & Debugging |
| Go Live | Are its triggers ready to accept real events? | Versioning |
| Monitor | Did the run start, and where is it now? | Activity |
| Diagnose | Which step first produced the wrong result or error? | Step-Level Executions |
| Recover | Is repeating the work safe, or did an external change already happen? | Error Handling & Retries |
1. Test the path in Draft
Draft disables automatic triggers but still allows manual runs. Use it to test the workflow without accepting scheduled, webhook, or app-triggered events.
Save a version before a risky change
A saved version is the point you can restore later. Editing or switching to Live does not create one automatically. See Versioning.
Test each uncertain step
Run the trigger or action on its own and read its Executions tab. For a trigger, Run with test data uses the saved Testing data. For an action, running the step performs that action, so use test accounts or records where a real write would matter.
Run from the trigger
Set the trigger as the run point and press Run to exercise the whole path. A run point in the middle skips everything before it, which is useful for focused debugging but is not an end-to-end test.
Check the values that leave the workflow
Open the destination and confirm the resulting message, row, ticket, or record. A green step means it completed; the destination confirms that it changed the right thing.
Use representative list sizes as well as representative fields. Plan limits and credit checks apply when the workflow runs, so a test with one item does not prove that a production batch of hundreds will fit.
2. Set the workflow Live
Live enables the workflow’s triggers. For a Webhook trigger, the endpoint appears only after the workflow is Live. For a Scheduler trigger, confirm the previewed run times and timezone before enabling it.
Draft is not a separate copy of the workflow. Edits change the same workflow, including while it is Live, and affect the next trigger. For a controlled change:
- Save the current version.
- Switch the workflow to Draft.
- Make the change and run an end-to-end test.
- Switch it back to Live.
Events that arrive while the workflow is in Draft are not replayed. Decide whether pausing the trigger is acceptable before taking an active workflow out of Live.
3. Monitor the run
Open Activity to confirm that the run started and see its status, timing, Step timeline, attempts, and error summary. From there, open the workflow on the canvas when you need the in-workflow Execution Log.
Once you know which Step needs attention, use its Executions tab to inspect the recorded output and trace the input from the preceding Step.
4. Diagnose and recover
Start with the Troubleshooting symptom index when a run did not start, remains waiting, or shows an unfamiliar message. It routes the symptom to the relevant check without repeating feature setup here.
For future runs, configure retry behavior and the route taken after retries are exhausted in Error Handling & Retries. For the current run, confirm any external changes before repeating work.
What’s Next?
- 👉 Activity →: monitor whole runs and alerts across the workspace.
- Versioning: save a known state and understand Draft versus Live before a controlled change.
- Troubleshooting & Common Errors: start from a symptom or exact error message.