Editing a workflow that is already running
What changes apply to cases in flight, what does not, and why.
On this page
The short version: changes apply to steps that have not run yet, on every case, including cases already open.
That is different from autonomy levels, which apply only to new cases. The two behave differently on purpose and it catches people out, so it is worth understanding why.
The reasoning
A workflow step is a piece of your process. If you fix a broken acknowledgement template, you want every case still waiting for an acknowledgement to get the fixed one — not just cases opened after Tuesday.
An autonomy level is a statement about how much human oversight a case received. Changing that mid-case would mean a case handled under two different oversight regimes, with no honest way to describe how it was handled. So autonomy is pinned at case creation.
What this means in practice
| Change | Cases already open |
|---|---|
| Edit a template | Applies to sends that have not happened |
| Add a step | Runs when its trigger next fires |
| Remove a step | Will not run, even if its trigger fires |
| Change a deadline | Applies from the next stage entry, not retrospectively |
| Change the autonomy on an action | Does not apply; new cases only |
Changing a deadline
Deadlines already counting are not recalculated. A case that entered stage two on Monday under a ten-day deadline keeps ten days, even if you change it to five on Wednesday.
Testing a change safely
Deactivate the workflow, edit, reactivate. While deactivated, no steps fire and cases sit still — which is safe for an hour and expensive for a day.
For anything larger, copy the workflow, edit the copy, point one case type at it, and watch.