Edit a template without breaking running processes

Here is a problem that drove us crazy for years.

You have a customer onboarding template. Forty-seven customers are currently being onboarded using that template. Their processes are active right now - tasks assigned, deadlines ticking, people working.

Now your legal team says you need to add a new compliance step.

What do you do?

The impossible choice

Most workflow tools force you into one of two bad options.

Option one: edit in place. You change the template directly. But what happens to those 47 running processes? In some tools, they break. The step order no longer matches what was launched. Data gets corrupted. In others, the running processes suddenly gain a new step mid-flight. People get confused.

Option two: freeze forever. You create a new version of the template. But now you have two templates to maintain - the old one still powering running processes, the new one for future launches. How long do you keep both? When is the old one safe to archive? What if you find a bug that exists in both?

Neither option is good. This is why we designed a dual-version system.

The core principle

The design came down to a simple rule:

Only the published version is the visible version.

When you launch a process, you see the published version. When you search for templates, you see the published version. When you select a template in “launch another process when this task is complete” - published version.

The draft version? Invisible. It exists only for the person editing it.

Draft versions should not be shown in: search results, any pickable list of blueprints, launch another process selections. The draft version is meant for private editing/work only.

This is not about hiding work in progress. It is about protecting running processes from changes that have not been validated yet.

The architectural debate

When we designed this, we debated two approaches:

At the highest level for schema/JSON response design, there are two architectural choices: maintain a single blueprint object with internal versions, or maintain multiple independent blueprint objects loosely linked.

Option two sounds cleaner at first. Separate objects, separate identities, loose linking. But it creates problems.

What happens when you want to see the activity history for a template? You need to aggregate across multiple objects. What happens when you archive a template? You need to find and archive all the linked objects. What happens when permissions change? You need to update all the linked objects.

Recommended approach: keep only a single blueprint object, but internally segregate versions so the default version returned is always the published version.

One ID. One object. Internal segregation. The API defaults to returning the published version unless you explicitly ask for the draft.

This keeps the mental model simple. A template is one thing. It just happens to have two states.

Why this took years

The concept sounds simple. The implementation was not.

The real complexity shows up in edge cases.

Activity logs

Every change to a template gets logged. But if you have two versions, which version owns which logs?

Activity items are tracked independently for each version. Upon merge and removal of draft version, all draft activity logs are deleted.

We debated this extensively. One option was to merge all draft activity logs into the published version. But that creates noise - do people really need to see every save of a work-in-progress draft?

The trade-off we made: draft activity logs are for the editor. Published activity logs are for the organization. When you merge, you get a summary, not a play-by-play.

The merge payload could contain all changes/diff between previous version and diffs at point of merge. This gives you a complete audit trail without cluttering the activity feed with intermediate saves.

Duplication rules

What if someone tries to duplicate a draft?

Can duplicate the published version. Cannot duplicate the draft version.

This prevents confusion. If you could duplicate a draft, you would end up with two drafts of the same template - one that someone is actively editing, one that is a snapshot copy. Which one is the real draft? Nobody knows.

Archiving rules

What happens when you archive a template that has a draft?

Cannot archive the draft on its own. Can archive the published version - archives everything, all versions, including draft.

Archiving is an all-or-nothing operation on the template as a whole. You cannot have an archived published version with an active draft. That state makes no sense.

Public/publish rules

Templates in our system can be made public - shared with anyone, not just your organization. The rules here are strict:

Can only public/publish the published version. Cannot public/publish the draft version.

You cannot share work in progress externally. If you want to share it, you need to merge it to published first. This forces validation before exposure.

Auto-launch integration

One of our most powerful features is auto-launching processes - when a task completes in one process, it can automatically start another process.

In Launch another process when this task is complete - only public versions of a blueprint show up. Draft versions are excluded from this selection.

This prevents a nightmare scenario: you have a draft with a broken step, someone else configures an auto-launch pointing to your template, and now every time they complete a task, it launches your broken draft.

The friction problem

While building this feature, we kept running into a more fundamental issue. As I noted at the time:

We need to really strengthen the basic use of Tallyfy to just document processes. That is where all the friction lies.

The draft/published system is sophisticated, but it only matters if people actually create templates in the first place. Before we could ship versioning, we had to make template creation itself simpler.

We need to split the ability to view a template vs editing a template. At present, you go straight to editing. Viewing would render a simple reading view.

This insight shaped the entire feature. Versioning is not just about protecting running processes - it is about giving people confidence that they can view a template without accidentally changing it. The draft state is explicit. You know when you are editing. You know when you are just looking.

How this relates to template variations

This draft/published system works hand-in-hand with template variations. Where variations solve the “fifteen slightly different copies” problem, dual versions solve the “editing breaks running processes” problem.

You can have one template with USA, China, and Australia variations - and each of those can be edited in draft mode without affecting running processes in any variation.

The variation you select at launch time pulls from the published version. Your draft edits to the China variation do not touch the 23 China processes currently running.

What the industry learned

Looking at how other workflow tools handle this same problem:

Next Matter’s approach: “Versioning allows you to make changes to workflows without them being immediately published. You can test the draft versions, while the current version in use remains unchanged.”

Patchworks states it directly: “The draft version can be edited freely without any possibility of changing or breaking the version that is currently deployed.”

Nintex uses a minor/major numbering system: “When you select to save a draft, a minor version of the workflow is created. The second digit of the version is increased, for example 1.0 to 1.1.”

GoFormz found the same insight: “Published changes do not impact forms created from a previous version of the template. Rather, each form will maintain the same template version that was available at the time the form was created.”

The industry has converged on this pattern because it solves a real problem. The variation is in how you expose it to users.

What we left out

Several capabilities got explicitly cut from this design:

Branching: We do not support multiple simultaneous drafts. One published version, one draft version, that is it. If two people want to make different changes, they need to coordinate. Branching creates merge conflicts, and merge conflicts in business processes are terrifying.

Rollback to draft: Once a draft is merged to published, it is gone. You cannot revert the published version back to a previous draft state. If you need to undo, you edit the published version into a new draft and merge that.

Draft sharing: Drafts cannot be shared with other team members for review before merge. The person editing the draft is the person who decides when it is ready. We considered adding review workflows for drafts but decided the complexity was not worth it for most teams.

Automatic versioning: We do not keep historical published versions. When you merge a draft, the previous published version is replaced. If you need historical versions, export before merge. This keeps the data model simple - one published, one draft, not an unlimited chain of historical versions.

Real-time collaborative editing: One early comment from our team captures this well:

I think the template creator has a ways to go, there are opportunities for: Google docs style editing with multiple people, Versioning users can take advantage of.

We deliberately did not build Google Docs-style collaboration. Multiple people editing the same draft simultaneously creates conflict resolution nightmares. For workflow templates - where a wrong step can break entire processes - we chose explicit coordination over implicit merging.

Full version history with rollback: We discussed keeping every historical version with the ability to roll back to any point. But this creates storage bloat and complexity. What happens if you roll back to a version that references a form field that no longer exists? What happens if dependencies have changed? The clean cut of “one published, one draft” avoids these edge cases.

Diff view between versions: While the system tracks what changed, we did not build a visual diff tool. You cannot see a side-by-side comparison of the draft versus published version with highlighted changes. This remains on the wishlist.

The deeper insight

The real insight is not about drafts and published versions. It is about respecting the contract between a template and its running processes.

When you launch a process from a template, you are making a promise: this process will work the way the template said it would work at launch time. Future changes to the template do not retroactively change that promise.

Most tools treat templates as mutable definitions. Change the template, change all processes using it. That is the database-thinking approach - templates are the schema, processes are the data, and the schema can be altered.

We treat templates differently. The template at launch time is a snapshot that the process owns. Future template changes create future snapshots. Running processes keep their original snapshot.

The draft/published split is just the implementation detail that makes this promise possible. You can edit templates freely because your edits cannot touch the snapshots that running processes depend on.

That is the real design goal. Everything else is just making it usable.

You can manage all these settings in your organization settings when you need to control who can edit templates and when changes get published.

Related questions

How do I know if my template has uncommitted draft changes?

The template editor shows a visual indicator when draft changes exist. You will see the current published version and the option to view or continue editing the draft. The system does not allow you to forget about a draft - it surfaces the state clearly.

What happens if I never merge my draft?

The draft sits there indefinitely. It does not expire. This can be useful - you can prototype changes without committing to them. But it can also create confusion if you forget about a draft and later wonder why your published version seems outdated.

Can running processes opt into new template changes?

No. Once a process is launched, it runs on the template snapshot from launch time. If you want running processes to pick up new changes, you would need to design that logic into the process itself using conditional steps that check for updates.

How does this interact with template permissions?

Permissions apply to the template as a whole, not to individual versions. If you can edit the template, you can edit both the published version and the draft. We did not build separate draft editing permissions because the complexity did not justify the use case.

Can I see a diff between the draft and published versions?

Yes. Before merging, you can compare the draft to the published version and see exactly what changed. The diff shows added steps, removed steps, modified form fields, changed rules - everything. This helps you validate that your draft is ready before you commit to it.

What about seeing full activity history?

One piece of feedback that shaped our thinking:

The main issue is the ability to see the full activity history of a completed run or completed task.

Activity history is critical for audit trails. The draft/published system preserves published activity completely - only the intermediate draft saves get consolidated on merge. For compliance-heavy industries, this means you always have a clear record of what happened and when.