Versioning

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:

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

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.

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 workflow or losing your published version.

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

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.