Version History

What is Version History?

Version History gives you control over when your changes go live. It separates your work-in-progress from what’s actually running in production. Here’s how it works:

You’re always editing a “working copy” (called the Draft)
Your edits don’t affect running automations until you choose to Publish
Publishing creates a snapshot of your work and makes it the Live version
Every published version is saved forever, so you can always go back

Simple analogy: It’s like writing in Word (Draft) vs publishing to a website (Live). You can edit all you want in Word without affecting what readers see on the website.

Understanding Draft vs. Live

Workflow where you build, edit, and test. Think of it as your sandbox — fully functional for testing, but changes don’t affect production automations. All edits happen here first.

Draft vs. Live: Quick Overview

	Draft	Live Version
What is it?	Your workflow where you build and test	The version running in production
Can you edit it?	✅ Yes - all edits happen here	❌ No - must restore to draft first
Can you run it?	✅ Yes - using the “Run” button manually	✅ Yes - runs only via triggers/interfaces/webhook
Do saves affect users?	❌ No - changes stay in draft	Live version remains unchanged
Triggers active?	❌ No - configured but inactive	✅ Yes - all triggers fire from here
Interfaces accessible?	Interface can be configured but not viewable by users	✅ Yes - users access this version
Webhooks use this?	❌ No	✅ Yes - API calls run this version
Effect of saving	Updates draft immediately	Live version remains unchanged
Effect of publishing	Creates a version that goes live	Updated to match the published version

The Simple Mental Model

Think of it this way:

Draft = Your personal workflow where you build and test (like a Word document)
Live = What’s actually running for users (like a published website) or running automatically in the background via triggers, interface or webhook.
Publish = Push your changes from draft to production

How Version History Works

The Flow of Work

Edit in Draft

Make all your changes in the draft

Test Your Changes

Use the “Run” button to test your draft flow

Save Progress

Saving updates your draft (not the live version)

Publish When Ready

Publishing makes your draft the new live version

Automation Runs

Triggers, interfaces, and webhooks use the live version

Real-World Example: Slack Notification Flow

Let’s say you have a flow that sends Slack notifications when new leads come in:

Day 1: Build Slack notification flow → DRAFT
       Test with sample data → DRAFT works
       Publish → LIVE (Slack trigger now active)

Day 2: New lead arrives → Slack trigger fires → LIVE version runs ✓
       10 AM: Add email notification feature → Editing DRAFT
       11 AM: Accidentally break Slack connection → DRAFT broken
       New lead arrives → Slack trigger still fires → LIVE still works ✓
       
Day 3: Fix the connection issue → DRAFT fixed
       Test both Slack + email → DRAFT works
       Publish → New LIVE version
       New lead arrives → New LIVE version fires → Both Slack + email notifications sent ✓

Publishing Your Changes

To make your draft changes live:

Click the Save dropdown arrow
Select “Save & Publish New Version”
Optionally add a version description
Confirm publishing

Important: Publishing is the ONLY way to update what runs automatically. Saving alone never affects triggers, interfaces, or webhooks.

Working with Triggers

Triggers are automated ways to start your flows - like scheduled runs, new Slack messages, or incoming webhooks. With Version History, triggers only fire from the published version, ensuring your automations remain stable while you edit the draft.

Critical: Triggers Require Publishing

Triggers are NEVER active until you publish. You’ll see the warning above when you save trigger changes without publishing.

Trigger Lifecycle

Here’s what happens to triggers at each stage:

Stage	Your Action	Trigger Status
Configuration	Add trigger + Save	❌ Inactive (exists in draft only)
Activation	Publish	✅ Active (now firing)
Modification	Edit trigger/flow + Save	✅ Old version still active
Update	Publish changes	✅ New configuration active
Removal	Delete trigger + Save	✅ Still active (using published version)
Deactivation	Publish deletion	❌ Trigger removed

Exception: Time Triggers

Important: Time-based triggers (scheduled runs) activate immediately upon creation. However, they always run the published version of your flow.

Working with Interfaces

Interfaces are the forms and UIs that users interact with to run your flows. Like triggers, interfaces serve the published version to ensure users always get a working experience while you iterate on improvements.

Interface Behavior at Each Stage

Stage	What You Do	Interface Status
Creation	Add interface + Save	Draft only
Going Live	Publish	Interface accessible at URL
Making Changes	Edit interface + Save	Old version still serves users
Updating	Publish changes	New interface version live
Removing	Delete interface + Save	Old version still accessible
Deactivation	Publish deletion	Interface removed (404)

Restoring Previous Versions

Restoration lets you bring back any previous version of your flow. This is useful when you need to revert changes or recover previous functionality.

What “Restore” Actually Does

Restore does NOT make a version live! It only copies that version’s content into your current draft .

When you restore a version:

The restored version’s content replaces your current draft
The live version remains unchanged
You must publish to make the restored version live

How to Restore and Publish

Open Version History

Click the history icon in the top navigation

Find Your Version

Locate the version you want to restore

Restore to Draft

Click menu (⋮) → “Restore as Draft” - this copies it to your draft

Version History panel showing draft and published versions

Review Changes

Check that your draft now matches the restored version and make any changes if needed

Publish

Click “Save & Publish” to make the restored version live

Viewing vs. Editing Versions

Can You Edit the Live Version?

Not directly. The live version is read-only to ensure stability. To modify a live version:

Restore the live version to your current draft
Edit the draft with your changes
Test using the Run button
Publish when ready to go live

This setup ensures you never accidentally break production automations while making changes.

Can You Run the Live Version?

The live version runs automatically through:

✅ Triggers (scheduled, Slack, webhooks, etc.)
✅ Interfaces (when users submit forms)
✅ API calls

You cannot manually run the live version from the editor. To test it manually:

Restore it to draft (note: this overwrites your current draft)
Run the draft version
Optionally restore your previous draft afterward

Best Practices

Always Test in Draft

Use the Run button to test thoroughly before publishing

Remember: Triggers Need Publishing

Triggers won’t activate until you publish

Use Meaningful Descriptions

Add clear descriptions when publishing for better history tracking

Check What's Live

Look for the green “Live” badge in version history

Frequently Asked Questions

Why can't I edit the live version directly?

I added a trigger but it's not firing. Why?

What does 'Restore' actually do?

My interface shows old content even after saving. Why?

What happens to running flows when I publish?

How do I test the live version without affecting my draft?

Do webhook URLs change between versions?

Why is my draft also 'live' in a sense?

What if I accidentally publish broken changes?

Are old versions stored forever?

Can I preview a version without restoring?

Helpful Reminders

Draft is Your Working Copy

What is a draft? Your draft is a working copy, and it’s fully functional. You can run it, test it, and share it. However, to actually add a trigger to it or run it via a webhook or interface, you must publish it first.

Restore ≠ Publish

Restoring an older version copies old content to your current working draft. You still need to publish it to make it live.

Save ≠ Publish

Saving updates your draft. Only publishing updates the live workflow.

Summary

TL;DR: Version History is like Git for no-code - you edit in a branch (draft) and merge to main (publish) when ready. Your automations keep running the stable version while you experiment safely.

Draft = Your testing playground (fully functional, but manual)
Published = Live version (what runs automatically)
Save & Publish = The only way to update the live version of the automation
Restore = Copy a historical version to the current working draft (doesn’t make it live)

Remember the golden rule: Save updates draft, Publish updates the live workflow.

Get Started

Nodes

Common Errors

Version History

What is Version History?

Understanding Draft vs. Live