Versions & publishing

​

Why versioning matters

Workflows evolve. You tweak a prompt, add a tool, restructure a branch. Without versioning, the only record of yesterday’s working workflow is whatever you remember — and one bad edit can break what’s running in production. MagOneAI solves this with two ideas working together: This lets you iterate freely on the canvas — experimenting, testing, refactoring — while the live workflow keeps running unchanged.

​

Automatic snapshots on save

You don’t create versions manually. Every time you save a workflow in Studio, MagOneAI checks whether the content has actually changed and records a new revision if it has.

​

Labels, notes, and pinning

Raw revision numbers aren’t very memorable. Three pieces of metadata help you make sense of history later:

• Label — a short human-readable tag like launch-candidate or pre-prompt-rewrite. Great for marking releases or baselines.
• Note — a longer message explaining what changed or why. This is what future-you will thank present-you for writing.
• Pin — protects a revision from being pruned when history hits the retention cap. Pin your released versions, safety baselines, and anything you might want to roll back to.

You can edit labels, notes, and pin state on any past revision at any time. The workflow content itself is immutable — that’s what makes versions trustworthy.

​

Draft vs published

A use case always has a published version — the one revision that executions actually use. Until you publish, the workflow in production is whatever was published last, regardless of how many drafts you’ve saved since. This separation is the core of safe iteration:

• Drafts pile up as you edit. You can save freely, walk away, come back tomorrow, keep experimenting. Production is unaffected.
• Publishing is an explicit action. When you’re happy with a draft, you publish it. That’s the moment the change reaches users.
• Triggers and schedules follow the publish pointer. Scheduled runs, API triggers, and chat-triggered workflows all resolve to the published version automatically — no config to update.

​

Testing a draft before publishing

You don’t have to publish to try out changes. When you run a workflow from Studio — for example, via the Run button or a test case — you can target the latest draft directly. This executes the in-progress revision without touching the published version, so you can validate behavior end-to-end before committing. A typical flow:

​

Rolling back

Because every past revision is preserved, rolling back is never a restore-from-backup operation — it’s just publishing an older revision. Your newer drafts aren’t lost — they stay in history. You can always publish forward again once the issue is fixed.

​

Working across projects

Workflow versions travel with a use case. When you export a use case for sharing with another project or team, the export captures the currently published revision. On import, the receiving project starts a fresh history from that point — each project maintains its own independent version timeline after that.

​

Next steps