# Save, version, and activate

> Understand what Save writes, when editing forks a new version, and what activation checks before a workflow goes live.

Saving and activating are separate actions on purpose. A saved workflow is a
design; an activated one is a design that is running.

## Outcome

The version you intended is the one that is live, and you know how to take it
offline again.

## 1. Save

Press **Save**. Nothing reaches the server before that, which is why you can
rearrange freely while you work.

The toolbar tells you where you stand:

| Indicator | Meaning |
|---|---|
| **Unsaved changes** | Edits pending on a version that has never been published. **Save** overwrites it. |
| **Draft changes** | Edits pending on a version that has been published. The button reads **Save as New Version** and saving forks. |
| Nothing | Everything is written. |

**Save** is disabled while the graph has a structural problem — a cycle, for
instance. Hover it to see why.

**Checkpoint:** the version number beside the workflow name is what you expect,
and no pending-changes indicator remains.

## 2. Understand versions

Every version of a workflow is its own record, sharing a group with the others.
The number sits beside the name in the header as `v1`, `v2`, and so on.

Editing a published version forks a new one rather than rewriting what is live.
A version that was never published keeps taking plain saves.

Back on the **Workflows** list, each workflow collapses into one row with a
version count. Expand it and every version is there with its state —
**Active**, **Inactive**, or **Draft** — its **Published** date, and
**Activate**, **Deactivate**, **Delete**, and **Open** as appropriate.

Deleting a version deletes its runs too, and cannot be undone. A version that
is active must be deactivated first.

**Edit details** changes the name and description without touching the graph or
forking anything.

## 3. Activate

Press **Activate**.

The button stays disabled while something obvious is wrong, and its tooltip
says which:

- *Save the workflow before activating*
- *Save changes before activating*
- *Fix invalid nodes before activating*
- *Add at least one trigger before activating*
- *Add at least one step before activating*
- *Connect every step to the flow. Some have no incoming path*
- *Re-sample stale sources before activating*

When it is enabled, the tooltip reads *This workflow will go live and start
running on its triggers*.

Pressing it runs the full check on the server, which can still refuse with a
message naming the first problem found. Every message and its fix is on
[Activation errors](/help/workflows/activation-errors).

Activating a version deactivates whichever version of that workflow was live
before, so exactly one version of a workflow ever runs.

**Checkpoint:** the workflow reads **Active**, and its row on the **Workflows**
list shows a **Published** date.

## 4. Deactivate

**Deactivate** takes it offline. Webhooks for that workflow start being
rejected with `404` and its schedules are cancelled.
Runs already in progress continue to completion.

Deactivating is always allowed and never forks a version, which makes it the
safe way to pause anything you are unsure about.

## Common problems

**The button says `Save changes before activating`.** Activation runs against
what is stored, not what is on your screen. Save first.

**Activation was refused with a limit message.** Your plan caps how many
workflows can be active at once — *Active workflows limit reached (3 of 3 in
use)*. Deactivate one you are not using, or contact support to raise it.

**I edited a live workflow and nothing changed.** Editing a published version
creates a new version. The old one is still the active one until you activate
the new one.

**I cannot delete a version.** It is active. Deactivate it first — the row's
message says *Deactivate this version before deleting it.*

## Next step

[Watch runs in Monitor](/help/run-troubleshoot/monitor-runs).