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)

Documentation Index