> ## 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 states
Workflows progress through different states during their lifecycle.
Draft workflows can be edited and tested but will not execute automatically. Use draft state to build, refine, and test automation before activation.
**What you can do:**
* Edit triggers and actions
* Add or remove workflow steps
* Test with manual triggers
* Validate workflow configuration
**Cannot:** Execute automatically based on triggers
Published workflows are active and respond to triggers automatically. All executions are logged and tracked. You can edit published workflows, and changes take effect only after you publish again.
Paused workflows stop accepting new runs while allowing in-flight executions to complete. This provides a controlled way to temporarily halt workflow execution.
**When to use:**
* Temporarily stop workflow activity during maintenance
* Allow running workflows to complete before making changes
* Gracefully wind down workflow execution
Deleted workflows are soft deleted, preserving historical records while removing them from active use. Execution history is preserved and can be restored by support if needed.
***
## Publishing workflows
Ensure your workflow has a trigger and at least one action
The system automatically checks for required fields, proper connections, and valid configurations
Address any highlighted issues before publishing
Confirm publication to activate your workflow
Check that the workflow appears in your active workflows list
You need appropriate permissions to publish workflows within a collection. Contact your workspace administrator if you cannot publish workflows.
***
## Validation requirements
Before publishing, workflows are validated to ensure they will work correctly.
**Requirements:**
* Exactly one trigger configured
* All required trigger fields completed
* Valid filters and conditions
* Proper channel or event selection
**Common issues:**
* Missing trigger configuration
* Invalid channel selection
* Incomplete filter conditions
**Requirements:**
* At least one action connected to trigger
* All required fields populated
* Valid dynamic references
* Proper integration permissions
**Common issues:**
* Missing required fields
* Invalid dynamic value references
* Disconnected integrations
**Requirements:**
* All actions connected to trigger or previous actions
* No orphaned steps
* No circular dependencies
* Valid execution flow
**Common issues:**
* Disconnected actions
* Circular references between steps
* Invalid execution order
**Requirements:**
* All referenced integrations connected
* Valid authentication credentials
* Proper API permissions
* Active integration status
**Common issues:**
* Disconnected integrations
* Expired credentials
* Insufficient API permissions
***
## Updating published workflows
Edit published workflows without stopping them. A banner appears at the top of the editor showing "This workflow has unpublished changes" with publish and discard options. The banner persists until you publish or discard.
When you are ready to apply your changes, choose a publish method:
| Method | Behavior | When to use |
| ------------------ | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| **Publish** | In-flight workflows continue uninterrupted. New runs use the updated configuration. | Most updates. Safer and less disruptive. |
| **Stop & Publish** | Stops all currently running workflows immediately. All new runs use the updated configuration. | Fixing critical bugs where existing runs must not continue with the old version. |
To abandon your edits, click **Discard changes** to revert to the last published version. All unpublished edits are removed. This cannot be undone.
The system shows how many active runs will be stopped when using "Stop & Publish" to help you make an informed decision.
Use "Stop & Publish" carefully. Stopping running workflows may interrupt in-progress automation. Coordinate with your team when stopping workflows that affect shared processes.
***
## Unpublishing workflows
Unpublish workflows to stop them from responding to triggers.
Click the **Unpublish** button on a published workflow
Select how to handle existing runs:
**Pause:** Running workflows continue until completion, but new runs are blocked. The workflow can be republished to resume. Recommended for most situations.
**Deactivate:** All running workflows are stopped immediately, new runs are blocked, and the workflow returns to draft state. Use only when an immediate stop is required.
The dialog shows how many active runs will be affected. Review and confirm your choice.
Deactivating a workflow stops running workflows immediately, which may leave processes in incomplete states. Coordinate with your team when deactivating workflows that affect shared processes.
***
## Tips
* **Test before publishing.** Test workflows in draft state with manual triggers and realistic data. Monitor the first few executions closely after publishing.
* **Use "Publish" by default.** Letting running workflows complete with the old version while new runs use the updated version is safer than stopping everything. Only use "Stop & Publish" for critical bug fixes.
* **Start with limited scope.** Begin with workflows that affect a small subset of tickets or users. Expand scope after verifying reliable operation.
* **Coordinate with your team.** Communicate with stakeholders before publishing workflows that affect shared processes.
* **Add descriptions.** Explain the workflow's purpose and any recent changes in the description. This helps team members understand updates and troubleshoot issues.
Learn more about [building workflows](/documentation/automate/workflows/workflow-builder) and [monitoring workflows](/documentation/automate/workflows/monitor)
## 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.