Workflow Versioning: How to Version and Publish Automations

Denis Kildishev -

Workflow versioning means every change to an automation creates a new version that can be tested, reviewed, published and rolled back, instead of editing the live workflow directly. As automations take on approvals, payments and customer messages, an unversioned edit can skip an approval step or email every customer twice. Versioning turns workflow changes into releases.

Why workflows need versioning

  • Safe changes: edit a draft while the published version keeps running.
  • Rollback: return to the last working version in one step when something breaks.
  • Accountability: know who changed what, when and why.
  • Compliance: prove which version of an approval process applied to a given transaction.
  • In-flight runs: runs started on the old version finish predictably.

Core concepts

Draft and published versions

Every workflow has one published version that handles live triggers and any number of drafts. Editing always happens in a draft; publishing promotes it.

Environments

Development, staging and production environments let you test a workflow against non-production data and credentials before it touches real records.

Version history

Each published version is kept with its author, timestamp and change notes, so you can compare and restore.

Run pinning

A run records which version it started on. Long-running workflows, such as a multi-day approval, should finish on the version they started with, unless you explicitly migrate them.

How to version and publish workflows

  1. Branch from the published version. Create a draft rather than editing live.
  2. Make one logical change per version. Smaller changes are easier to review and roll back.
  3. Write a change note. "Raise manager approval threshold from $1,000 to $2,500 per finance policy."
  4. Test in a non-production environment. Run the happy path and the main exceptions with test data.
  5. Review. Have a second person check changes to approval, payment or permission logic.
  6. Publish. New runs use the new version; in-flight runs continue on theirs.
  7. Monitor. Watch run errors and outcomes for the first day.
  8. Roll back if needed. Republish the previous version, then fix the draft.

Versioning in Git

Some platforms sync workflows and apps to a Git repository. That brings pull requests, code review, diffs and CI checks to automation changes, so workflows follow the same release process as your code. It also means your automations exist outside the vendor's system as a readable record.

Release checklist

  • Change note written and linked to the request or ticket.
  • Tested in a non-production environment with realistic data.
  • Exceptions and error paths tested, not just the happy path.
  • Credentials and connections point to the right environment.
  • Reviewer approved changes to approvals, payments or permissions.
  • Plan for in-flight runs decided.
  • Rollback version identified.

Common mistakes

  • Editing live workflows "just for a quick fix".
  • Testing against production data and sending real emails.
  • Changing several things at once, making failures hard to trace.
  • Forgetting that long-running approvals may be mid-flight.
  • No change notes, so nobody knows why a step exists six months later.

Workflow versioning in Jet Admin

Jet Admin includes version control and environments from the Pro plan, so you can build and test workflows and apps away from production and publish when ready. 2-way GitHub sync, also on Pro, keeps apps in your repository for pull requests and review. Audit logs on the Business plan and above record who changed what. Workflows run on your data across 200+ integrations, with unlimited workflows on every plan. See also our guide to workflow security.

Frequently asked questions

What is workflow versioning?

Keeping every change to a workflow as a separate version that can be tested, published and rolled back, instead of editing the live workflow.

What happens to running workflows when I publish a new version?

Typically, in-flight runs continue on the version they started with and new runs use the new version. Check how your platform handles it.

Do I need separate environments for workflows?

For anything touching payments, customers or permissions, yes. Testing against production data risks real side effects.

Can workflows be stored in Git?

Some platforms support Git sync, which adds pull requests, diffs and review to workflow changes.

Treat automation changes like releases

Start with Jet Admin for free and build workflows you can version, test and publish safely.