---
title: Versioning
description: Manage notiflow versions and publishing
---

Notiflows uses a versioning system that lets you safely make changes without affecting live notifications. You edit a draft, and when ready, publish it to make it live. Previous published versions are automatically archived.

## Version States

Each version has one of three states:

| State | Description |
|-------|-------------|
| **Draft** | The working version you're actively editing. Only one draft exists at a time. |
| **Published** | The live version that executes when the notiflow is run. Immutable — cannot be edited. |
| **Archived** | A previously published version that was replaced by a newer publish. Kept for history. |

## How Versioning Works

When you trigger a notiflow, it always uses the **published** version. Your draft changes don't affect live notifications until you publish.

```
Create notiflow → Edit draft → Publish → Edit new draft → Publish → ...
                                  │                           │
                                  └─ archived                 └─ previous published → archived
```

## Publishing

When you publish a notiflow:

1. The draft is validated — steps, templates, and connections are checked for correctness
2. The current published version (if any) is moved to **archived**
3. The draft becomes the new **published** version
4. A new draft is created for future edits
5. All future runs use the newly published version
6. In-flight runs (already triggered) continue with their original version

<Callout>
Publishing validates the flow structure before going live. If there are issues — like a channel step with no template, or a disconnected step — the publish will fail with specific error messages.
</Callout>

## Draft Changes

While editing a draft, you can:

- Add, remove, or reorder steps
- Change step configurations (channels, wait durations, conditions, etc.)
- Edit template content
- Add or remove branches on condition steps

None of these changes affect the published version until you explicitly publish.

## Activating and Deactivating

Notiflows have an **active** toggle that is separate from versioning:

| State | Behavior |
|-------|----------|
| **Active** | Can be run via the API. Uses the published version. |
| **Inactive** | Cannot be run. API calls return a `409 Conflict` error. |

Deactivating a notiflow is useful when you need to temporarily stop notifications without deleting the notiflow or losing your published version.

<Callout>
A notiflow must be both **active** and have a **published version** to be runnable. If either condition is missing, the API returns an error.
</Callout>

## Best Practices

- **Test before publishing** — Use the preview and test features to verify your changes work correctly before publishing.
- **Publish intentionally** — Review all draft changes before publishing. Published versions are immutable.
- **Use deactivation over deletion** — If you need to stop a notiflow temporarily, deactivate it rather than deleting it. You can reactivate it later without losing your configuration.