# Editing a live workflow - Docs

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](/docs/workflows/troubleshooting.md) 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](/docs/workflows/workflow-builder.md#draft-and-enabled-workflows): draft vs. enabled states and validation
-   [Best practices](/docs/workflows/best-practices.md): planning, versioning, and testing changes safely
-   [Troubleshooting](/docs/workflows/troubleshooting.md): debugging individual runs and their logs

### Community questions

Ask a question

### Was this page useful?

HelpfulCould be better