# Versioning

> Save a version of a workflow before you change it, and restore an earlier one if a change goes wrong.

Versioning answers: **How do Draft, Live, and saved versions relate when I change a workflow?** Use it to preserve and restore known workflow states; use [Operating Workflows](/build/core-concepts/operating-workflows) for the full test-to-Live process.

Two things to know before you rely on versions: you save them yourself, and Draft controls whether triggers fire rather than holding a private copy of your edits.

## Saving a version

**You save a version when you want one.** Give it a title and a description,
and Glow snapshots the workflow as it stands. Editing a workflow or switching it
to Live does not create one.

There is one exception. A checkpoint is taken before the [Workflow
Assistant](/build/ai-features/workflow-assistant) generates into a workflow that
already has steps. An assisted change is recoverable even if you did not think to
save first.

> **Save a version before a change you would not want to redo by hand.** If you
> have not been saving them, there is nothing to go back to. This is the point
> people discover the hard way. Treat it like a commit: cheap to make, and only
> useful if you made it beforehand.

## Draft is a trigger switch, not a staging area

The status control offers two states. **Draft** is _triggers disabled, manual
runs only_. **Live** is where triggers fire.

That is all it does. **There is one copy of a workflow, and edits take effect
the moment you make them**, including while it is Live. Draft does not hold a
private copy for you to work on and release later. It stops the workflow being
triggered, nothing more.

> Editing a Live workflow changes what runs on the next trigger, immediately.
> There is no publish step between your edit and production. To change a busy
> workflow safely, save a version first. Switch to **Draft** so triggers stop
> firing, make the change, test it with **Run**, then switch back to **Live**.
> Events arriving while it is in Draft are not processed, so weigh that against
> the risk of editing in place.

## Restoring an earlier version

Open **Version history** from the canvas menu. Each entry shows its title,
description, author and date.

**Restore** replaces the current workflow with that version, in full. Restores
are themselves recorded, so the history shows what was rolled back and when.

> **Restore replaces the current workflow in full.** Save a version of the
> current state before restoring an older one. Even a throwaway titled "before
> rollback" makes the step reversible.

**Write descriptions that will still mean something to you in three months.**
The list is what you navigate by. The description is what tells one version
from another.

**To see an older version's canvas, restore it and look.** Save the current
state as a version first and you can come straight back, so restoring is a way
of browsing rather than a commitment.

## What's Next?

- 👉 **[Operating Workflows →](/build/core-concepts/operating-workflows)**: test a controlled change and take the workflow Live.
- **[Activity](/manage/workspace-settings/activity)**: monitor the whole run after a change or restore.
- **[Step-Level Executions](/build/core-concepts/executions)**: inspect what one Step received and produced.
