Save And Publish Workflows
Save drafts, publish active versions, and avoid invalid workflow graphs.
Saving keeps your draft. Publishing makes the workflow version active.
Treat draft and published workflows separately. A draft is where you can safely change nodes and configuration. The published version is what new workflow runs use.
Save A Draft
- Open the workflow builder.
- Add or edit nodes.
- Fix any visible graph warnings.
- Select Save.
Drafts are useful while building and testing.
Save before leaving the builder, before testing a new branch, and before making large changes to a working workflow. If multiple admins edit workflows, agree on who owns the draft before changing a production automation.
Publish A Workflow
Publish only after the workflow has one trigger, valid connections, required configuration, and a successful test run with safe data.
If publish warnings appear, review the issue list and fix the workflow before publishing.
For workflows that send messages, create invoices, update customers, or call an integration, test with a record that cannot harm a real customer. A successful graph validation does not prove the business outcome is safe.
Version Ownership
Assign one owner for production workflow changes. If several admins edit the same workflow, agree who owns the draft, who tests it, and when it should be published.
Record the reason for major workflow changes in your internal notes or the workflow description. This helps later when reviewing why an automation started creating different records or messages.
Pre-Publish Checklist
- The workflow has one clear trigger.
- Every required trigger and action field is filled.
- Nodes are connected in the intended order.
- Conditions have tested true and false paths.
- Delays use production timing, not temporary test timing.
- Actions that create or update records use the correct owners, statuses, and linked records.
- Notifications use customer-safe copy when customers may see the message.
- A test run completed with safe data.
After Publishing
Submit or trigger one real but low-risk example and open the run detail. Confirm that the trigger payload, step sequence, created records, and final status match the workflow design.
If the workflow handles customer communication, verify the actual message in the destination system. If it creates internal work, open the created task, ticket, deal, or project record and confirm ownership and due dates.
Updating a Published Workflow
When you change a published workflow, save the draft, test the changed path, and publish again. Existing runs may continue with the version they started on, so review active runs before making major structural changes.
For customer-facing workflows, review message copy, recipients, and duplicate send risk before publishing. A structurally valid workflow can still create a bad customer experience.
If a workflow is already causing incorrect output, pause or narrow the trigger before editing. Then fix, test, and publish the corrected version.
When Not to Publish
Do not publish when required fields are missing, warnings are visible, the workflow has not been tested, or the automation could create duplicate customer messages. Keep it as a draft until the run detail proves the workflow behaves correctly.
If you are not sure, publish to a narrow condition or safe test record first, then broaden the trigger after the first runs are reviewed.
Post-Publish Review
After publishing, review the first few runs instead of assuming the workflow is done. Confirm the trigger fired for the right records, conditions routed correctly, actions used the intended owners/statuses, and no duplicate customer messages were sent.