Versions & publishing

Iterate on workflows safely — keep a full history of changes and control which version runs in production

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:

Draft history

Every meaningful save becomes an immutable revision you can inspect, compare, and restore.

Published version

One specific revision runs in production at any time. Editing on the canvas doesn't ship until you explicitly publish.

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.

You save changes on the canvas

Add a node, rewrite a prompt, reroute a branch — any edit that changes the workflow.

MagOneAI de-duplicates cosmetic saves

If the underlying workflow is identical to the last revision (for example, you opened a use case and re-saved without editing), no new revision is recorded.

A new revision is recorded

New content becomes the next revision in history, stamped with the author and timestamp.

Older history is pruned

To keep history bounded, the oldest unpinned revisions are removed once you exceed the retention limit. Pinned revisions are always kept.

Revisions capture both the workflow graph and the canvas layout — so restoring an older revision brings back exactly what you were looking at that day.

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.

Before a big refactor, pin the current revision and label it something like before-<change>. Even if you churn through many drafts afterwards, that safety point stays available.

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.

Saving is not shipping. If you want a change to reach production, you have to publish.

Unsaved work is never lost

Studio autosaves your in-progress edits locally as you work — so a tab close, accidental navigation, or browser refresh won't lose changes you hadn't explicitly saved yet.

As you edit the canvas and node property panels, your work is continuously kept as a local draft.
If you leave a use case with unsaved changes, Studio confirms and preserves them as a draft.
When you return, if your local draft is newer than the last saved revision, Studio restores it and shows a "Restored unsaved changes from your last session" notice with an option to Discard and reload the saved version instead.
Once you save (or save and publish), the local draft is cleared — the revision history becomes the source of truth.

This local autosave is about not losing keystrokes between saves. It's separate from revision history and the published version, which are what actually run. Saving still creates the durable revision; publishing still controls what production uses.

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:

Edit on the canvas

Make your changes. They save as drafts automatically.

Run the draft with sample input

Use Studio's run panel (or a test case) to execute the latest draft and review the output.

Iterate until it's right

Each save is a new revision you can go back to if needed.

Publish when you're confident

Promote the revision you just validated to be the new published version.

Rolling back

Because every past revision is preserved, rolling back is never a restore-from-backup operation — it's just publishing an older revision.

Open the versions panel

In Studio, open the history for the use case. You'll see every revision with its label, note, author, and timestamp.

Find the revision you want

Labels and notes help you identify the right one. You can preview a revision's workflow before acting.

Publish it

Publishing an older revision makes it the new live version. Subsequent runs, schedules, and triggers immediately use it.

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.

Share via export/import when you want a one-time handoff. Keep use cases in a shared project when you want a single source of truth that all teams see updates to.

Publishing also has two effects beyond your own project:

A published workflow can be listed in the catalog as a Blueprint, which any organization can copy into their own project. Only a published version can be snapshotted.
A published workflow becomes a callable capability for any Super Agent in the same project. Unpublishing one removes it from every Super Agent's tool belt immediately, including mid-run.