> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Publish

> Publish Ravenna workflows to activate triggers, then manage draft, published, and paused states as your automation requirements change over time.

Publish workflows to activate automatic execution based on configured triggers. Manage workflow lifecycles by updating, pausing, and unpublishing workflows as your processes change.

## Workflow lifecycle states

| State         | Accepts new runs | In-flight runs         | Editable                          | Can transition to                        |
| ------------- | ---------------- | ---------------------- | --------------------------------- | ---------------------------------------- |
| **Draft**     | No (manual only) | N/A                    | Yes                               | Published                                |
| **Published** | Yes              | Running                | Yes (creates unpublished changes) | Paused, Draft (via Deactivate)           |
| **Paused**    | No               | Continue to completion | Yes                               | Published, Draft (via Deactivate)        |
| **Deleted**   | No               | Stopped                | No                                | N/A (soft delete, restorable by support) |

***

## State transitions

* **Draft to Published:** Requires passing validation (trigger configured, actions connected, no orphans, no cycles, integrations active, required fields populated).
* **Published to Published (update):** Two methods:
  * **Publish:** In-flight runs continue with old version. New runs use updated version. Default choice for most updates.
  * **Stop & Publish:** Stops all in-flight runs immediately. All new runs use updated version. Use only for critical bug fixes where old-version runs must not continue.
* **Published to Paused:** Stops accepting new runs. In-flight runs complete. Use for temporary maintenance or gradual wind-down.
* **Published to Draft (Deactivate):** Stops all in-flight runs immediately and blocks new runs. Use only when immediate stop is required.
* **Paused to Published:** Resumes accepting new runs.

***

## Publishing validation

The workflow engine checks before publishing:

* Exactly one trigger with all required fields.
* At least one action connected to the trigger.
* All nodes reachable from trigger (no orphans).
* No circular dependencies.
* All required fields populated on every node.
* All dynamic value references point to valid upstream steps and fields.
* All required integrations are connected and authenticated.

***

## Editing active workflows

When a published workflow is edited, changes are held as an unpublished draft overlay. The published version continues running unchanged until changes are explicitly published or discarded.

* **Publish** applies changes to new runs only. In-flight runs are unaffected.
* **Stop & Publish** stops in-flight runs, then applies changes to all new runs.
* **Discard** reverts to the last published version, removing all pending edits.

***

## Recommendations

* **Default to Publish over Stop & Publish.** Letting in-flight runs complete with the old version avoids interrupting active processes. Stop & Publish should be reserved for critical bug fixes.
* **Test in draft mode before publishing.** There is no staging environment. Manual triggers with realistic data are the primary testing mechanism.
* **Start with limited scope.** Filter triggers narrowly at first (specific channel, specific category). Widen scope after confirming the workflow works reliably.
* **Coordinate team communication.** Workflows that affect shared processes should be published with team awareness. Unexpected automation changes can disrupt operations.