Editing a live workflow
Contents
You can edit a workflow while it's enabled and people are moving through it. PostHog uses a follow-live model: every step of every run reads the current published configuration, so your edits reach people who are already mid-workflow, not just people who enter afterwards.
This page explains exactly what happens to people already in a workflow when you change it, so you can edit live workflows with confidence.
The general model
A few principles explain almost every case:
- Runs follow the published config. There's no per-run snapshot of the old workflow. When someone's run reaches its next step, that step runs against whatever is published at that moment, so a fix you publish reaches people already in the workflow.
- Only a person's position is carried across an edit. A run remembers which step it's on (or waiting in), not a copy of the workflow it started with.
- The past doesn't re-run. Steps you add behind where someone already is never execute for them. They only ever move forward.
- In-progress sends complete as prepared. If a message has already been rendered and queued when you edit it, that copy still sends. The next person to reach that step gets the new version.
- Journeys are traceable, not versioned. No single saved config describes what one person experienced. Instead, each run's logs and results show exactly what that person got and when.
You can stage changes to an enabled workflow as a draft and publish them when you're ready. Nothing below happens until you publish. Each publish appears in the workflow's History tab, so you can see what changed and when.
Edits propagate to running workers within about 30 seconds, so there's a brief window after you publish where a step may still run against the previous configuration.
What happens for each type of edit
The tables below break behavior down by where a person is relative to the step you changed:
- Before the step: hasn't reached it yet
- Waiting at the step: currently parked in a delay, time window, or wait condition
- Past the step: already moved on
Timing edits
| Edit | People before the step | People waiting at the step | People past the step |
|---|---|---|---|
| Shorten a delay | Wait the new, shorter delay when they arrive | Switch to the shorter delay within minutes of publishing. Anyone already past it advances (see the caveat below) | Unaffected |
| Lengthen a delay | Wait the new, longer delay when they arrive | Re-park for the remaining time when their timer next fires | Unaffected |
| Change a time window | Use the new window when they arrive | Re-evaluated against the new window within minutes of publishing | Unaffected |
| Change a wait-until condition | Use the new condition when they arrive | Re-checked against the new condition within minutes of publishing. Runs that now match advance; the rest keep waiting | Unaffected |
Content and structure edits
| Edit | People before the step | People waiting at the step | People past the step |
|---|---|---|---|
| Edit message or action content | Get the new content when they arrive | Get the new content when they arrive | Already-sent messages are never resent or updated. A message already rendered and queued sends with the old content |
| Add a step | Execute the new step when they reach it | Execute it if it's ahead of where they're waiting; a step added behind them never runs | A step added behind them never runs |
| Remove a step (nobody waiting in it) | Skip straight past it | Unaffected (they're waiting elsewhere) | Unaffected |
| Reroute an edge | Follow the new path when they arrive | Follow the new path on their next move; messages already sent are never repeated | Unaffected |
| Delete a step people are waiting in | Skip straight past it | Move to the deleted step's next step within minutes of publishing, or exit the workflow if it no longer has a next step for them (see below) | Unaffected |
Variable edits
| Edit | Effect |
|---|---|
| Add a variable | Available to steps that set and read it going forward. A run that never passed the step that sets it will see it empty |
| Rename or delete a variable | A step that references a variable a run never had renders it empty. This is logged as a warning on the run so you can spot it |
Caveats worth knowing
Read before editing timing on a live workflow
- Shortened delays take effect within minutes, not instantly. If someone is 6 days into a 7-day delay and you shorten it to 3 days, they advance shortly after you publish. When many people are overdue at once, their wakes happen over a few minutes rather than at the same moment.
- Deleting a step someone is waiting in moves them forward or exits them. If the workflow has a next step where the deleted one was, they move there and continue. If not, they leave with the exit reason
exited_workflow_changed. This counts as a completed exit, not an error. - A step that reads a variable set by a newly added upstream step sees it empty for people who were already past that point when you published.
Related
- Workflow builder: draft vs. enabled states and validation
- Best practices: planning, versioning, and testing changes safely
- Troubleshooting: debugging individual runs and their logs