Skip to main content
Publish workflows to activate automatic execution based on configured triggers. Manage workflow lifecycles, create new versions, and handle updates to production automation.

​
Workflow states

Workflows progress through different states during their lifecycle.

Draft

Draft workflows can be edited and tested but won’t 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 ready to respond to triggers. They execute automatically and can be edited while maintaining service.What happens:
  • Trigger is registered with monitoring system
  • Workflow executes automatically when trigger conditions are met
  • All executions are logged and tracked
  • Workflow appears in active workflows list
  • Changes can be made without stopping execution
  • Changes take effect only after publishing
Deprovisioned workflows are immediately stopped by killing running executions and unregistering triggers. With edit-while-published, deprovisioning is less common since you can update workflows without stopping them.What happens:
  • Running executions are killed immediately
  • Trigger stops listening for new events
  • Workflow moves to inactive state
  • Historical logs are preserved
Use Pause to prevent new workflows from starting while allowing in-flight workflows to complete.
Deleted workflows are soft deleted, preserving historical records while removing them from active use.What happens:
  • Workflow removed from active lists
  • Execution history preserved
  • Can be restored by support if needed
  • Permanent deletion occurs after retention period

​
Publishing workflows

Publish workflows to make them active and ready to respond to triggers.
1

Complete workflow configuration

Ensure your workflow has a trigger and at least one action
2

Validate workflow

The system automatically checks for required fields, proper connections, and valid configurations
3

Fix validation errors

Address any highlighted issues before publishing
4

Click Publish

Confirm publication to activate your workflow
5

Verify activation

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
  • Insufficient permissions
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. Choose how to apply changes when publishing updates.
1

Edit the workflow

Make changes to triggers, actions, or configuration while the workflow remains published
2

Review unpublished changes

A banner appears showing “This workflow has unpublished changes” with publish and discard options
3

Choose publish method

When ready to publish:Publish - Apply changes to new runs only
  • In-flight workflows continue uninterrupted
  • New runs use updated configuration
  • No interruption to running workflows
Stop & Publish - Apply changes to all runs
  • Stops all currently running workflows immediately
  • All new runs use updated configuration
  • Use when you need all workflows to use the new version and existing workflows can be killed abruptly
4

Discard changes (optional)

Click “Discard changes” to revert unpublished edits and restore the last published version
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.

​
Managing unpublished changes

Track and manage edits made to published workflows before publishing updates.
A floating banner appears at the top of the workflow editor when you have unpublished changes. The banner shows:
  • Clear indication that changes are unpublished
  • Quick access to publish or discard actions
  • Persistent reminder until changes are published or discarded
Choose between two publish methods:Publish:
  • Leaves running workflows intact
  • Only affects new workflow runs
  • Recommended for most updates
  • No interruption to running workflows
Stop & Publish:
  • Stops all running workflows first
  • Affects both existing and new runs
  • Use when immediate consistency is required
  • Shows count of workflows that will be stopped
Revert unpublished changes to restore the last published version:
  • All unpublished edits are removed
  • Workflow returns to last published state
  • Cannot be undone (unless you republish the changes)
  • Useful for abandoning experimental changes
Ravenna tracks the difference between your published version and current edits:
  • Only the latest published version is tracked
  • Each publish creates a new version in history
  • Discarding changes removes all unpublished edits at once
  • No partial change tracking or staging

​
Best practices

Thoroughly test workflows in draft state before publishing. Use manual triggers to verify each step works correctly with realistic data.
Communicate with stakeholders before publishing workflows that affect shared processes. Ensure team members understand what the automation will do.
Watch newly published workflows closely for the first few executions. Verify they behave as expected and handle real-world conditions correctly.
Add clear descriptions to workflows explaining their purpose and any recent changes. This helps team members understand updates and troubleshoot issues.
Consider what happens if steps fail. Add conditional logic or error handling to ensure workflows degrade gracefully.
Begin with workflows that affect a small subset of tickets or users. Expand scope after verifying reliable operation.
Use “Publish” by default to avoid disrupting running workflows. Only use “Stop & Publish” when:
  • You need to stop existing workflows to ensure all future runs use the new version
  • You’re fixing a critical bug and need to prevent any workflows from running with the old version
  • The change is urgent and existing workflows can be killed without issue
For most updates, letting running workflows complete with the old version while new runs use the updated version is safer and less disruptive.