Workflows
How to edit an existing workflow
You will not get a workflow right first time. You will get it roughly right, watch three real runs, and then change it — so editing is the normal state of a workflow, not a repair.
I built both this builder and the deploy script in the story further down, which is why this page spends more words on confirming a change than on making one.
Edit it
- Open the workflow and click Edit to open the builder.
- Add or remove steps by dragging from the Step Toolbox — your agents, or Condition, Delay and Transform.
- Re-order steps on the canvas, or click one to change its agent, timeout or retries.
- Change the Execution Mode or the Trigger if the shape of the job has changed.
- Save. This bumps the workflow to a new version and keeps the old one.
What saving actually does
| What happens | |
|---|---|
| The version number | Increments by one on every save |
| The previous definition | Kept, so history is intact |
| Runs already finished | Untouched — they record the version they ran on |
| A schedule on this workflow | Keeps firing, and picks up the new definition on its next run |
That last row is the one that bites. A workflow on a schedule starts using your change at its next scheduled time, not when you hit Save, so a nightly workflow edited at noon is still running the old shape until tonight.
Test the change
The fastest test is Replay on a past run: it uses the workflow’s current definition with the original run’s input, so you are re-testing against the exact data that exposed the problem.
Replaying is not an expensive way to check yourself. A two-step support run of this kind comes to $0.0144 in our worked example, and one that fails on its first tool call $0.0024 — so replay the broken input rather than reasoning about whether the fix works.
Two things refuse a Replay before it starts. The workflow has to be Active. And on the free plan only sequential workflows run, so replaying a parallel, conditional, fan-out or loop workflow on a free account returns an error rather than a run.
Confirm it took effect, do not assume
Saving tells you the definition changed. It does not tell you the behaviour changed. Those are different claims, and the gap between them is where changes get lost.
Source: I deployed a deletion, watched five green checks pass, and found the deleted job still running. Every check was honest. None of them was about the thing I had just changed.
So after an edit, look at the first real run and check the specific thing you changed — the step you added is in the step rows, the condition you fixed took the branch you expected, the count is no longer zero. One look at one run, at the thing you actually touched.
Source: a readable run, and a failed one if you want to see what you are looking for before you need it. A two-step run of that size comes to $0.0144 in our worked example, so re-running one to check a change is not a cost worth thinking about.
When the change seems not to apply
The next run looks identical
Check which version that run recorded. If it is the old number, the run started before you saved, or it was a scheduled run that fired first.
Replay is refused
The workflow is Inactive, or it is a non-sequential workflow on a free account. Both return an error rather than running.
You want the previous behaviour back
The old definition is still there. Roll back rather than trying to re-type what it used to be from memory — that is what the version history is for.
Next
- Read a run that went wrong — see How to troubleshoot a failed run.
- Check what a scheduled workflow is really doing — see Automate: schedules & webhook triggers.