Publishing Workflows

Publishing workflows moves them from development to production, enabling automatic execution based on configured triggers. Understanding workflow states and the publishing process helps you maintain reliable automation for your team.

​

Workflow States

Workflows progress through different states during their lifecycle. Draft workflows can be edited and tested but won’t execute automatically. This gives you a safe environment to build and refine your automation before it goes live.

Publishing a workflow makes it active and ready to respond to triggers. Active workflows run automatically but cannot be edited. This prevents accidental changes to production automations while ensuring they operate consistently.

When you need to make changes to an active workflow, you create a new version in draft state, make your modifications, and then publish it to replace the active version. The system handles the transition smoothly, ensuring continuous operation of your automation.

Workflows can also be deprovisioned, which gracefully shuts them down by completing any running executions and unregistering triggers. Deleted workflows are soft deleted, preserving historical records while removing them from active use.

​

Publishing Process

Before publishing, the system validates your workflow to ensure it will work correctly. This includes checking that you have exactly one trigger, all steps are properly connected, and required fields are filled out. The system also verifies that any integrations have proper permissions and connectivity.

The publishing process registers your trigger with the monitoring system so it can listen for relevant events. Once published, your workflow is ready to respond automatically to the conditions you configured in your trigger.

You need appropriate permissions to publish workflows within a collection. This ensures that only authorized team members can activate automations that affect your production systems.

​

Managing Published Workflows

Monitor your published workflows to ensure they’re working as expected. Check execution frequency, success rates, and any error patterns that emerge. This helps you identify potential issues before they impact your team’s processes.

Since active workflows cannot be edited, making changes requires creating a new version. Copy the active workflow to create a new draft, make your modifications, and thoroughly test the updated version before publishing it to replace the current active workflow.

The system provides detailed logs for every workflow execution, making it easy to understand what happened and troubleshoot any issues. Use these logs to verify that workflows are performing as expected and to debug any unexpected behavior.

​

Best Practices

Test your workflows thoroughly before publishing them. Use manual triggers to verify that each step works correctly and produces the expected results. Test with realistic data that represents the actual conditions your workflow will encounter in production.

Document your workflows clearly, including their purpose, dependencies, and any special considerations. This helps team members understand what the workflow does and how to maintain it over time.

Start with simple workflows and gradually increase complexity as you gain experience. It’s better to have several focused workflows that each handle specific scenarios well than one complex workflow that tries to handle everything.

Monitor your workflows regularly and be prepared to make adjustments based on how they perform in practice. Real-world usage often reveals optimization opportunities or edge cases that weren’t apparent during initial development.

Coordinate with your team when publishing workflows that affect shared processes. Ensure that stakeholders understand what the automation will do and how it might change existing workflows.