Editing live sequences and version history

What it does

An active sequence can be changed without taking it offline. Selecting Edit sequence creates a new version, you make your changes, and reactivating publishes that version with a description of what changed. Records already running stay on the version they were connected to.

Key facts

Edit sequence is the in-place route: it creates a new version and the sequence stays active throughout. No downtime and no gap where records can't be connected.
Records connected to an earlier version remain on that earlier version. Only records connected after publication pick up the new one.
Reactivating prompts for a description of the changes. That description is the only narrative record of why a version exists, so treat the box as documentation rather than a nuisance.
Version history is under Show full version history, in the dropdown next to the sequence name. The list opens in the right pane with the currently selected version marked.
The Connected records tab is version-aware — you can see which records are sitting on which version.
The alternative to versioning is the old route: deactivate, edit, reactivate. Only inactive sequences can be edited directly.
Create a copy takes a full snapshot of the sequence — every step and setting as at that moment — under a new name and description, with Save and edit or Save and close.
A copy is completely independent of the original. Nothing links them and no changes propagate.
Editing requires the administration and customisation roles, or ownership of the sequence via an assignment.
Some settings can't be changed while the sequence is active at all. Exit criteria, for example, needs an inactive or revision state.

When to use / skip

Use Edit sequence for anything that changes a live cadence in production. Deactivating a sequence that sellers are actively working is disruptive in a way that isn't obvious until you do it — connection stops, the sequence disappears from the picker, and someone raises a ticket within the hour.

Use Create a copy when the change is big enough that you'd want to test it, when you're forking a cadence for a different region or product, or when the existing sequence is a mess and rebuilding is cheaper than editing. The copy is genuinely independent, which is what you want for experiments and exactly what you don't want if the client thinks they're getting a template with inheritance.

There is a case for skipping versioning entirely on a young implementation. If nobody has been connected to the sequence yet, deactivate and edit is simpler and leaves less clutter in the version list. Save the versioning discipline for cadences with real records on them.

Configuration decisions

Whether changes are made in place with versioning or by copying and switching over — different clients want different levels of ceremony.
What goes in the change description on every activation, agreed as a convention so the version list reads as a changelog.
Whether in-flight records should be migrated onto the new version, and if so how, given the platform leaves them where they are.
The naming convention for copies, because a list of near-identical sequence names against a 250 active cap gets unmanageable quickly.
Who is allowed to publish a new version of a live sequence — this is effectively production change control for what sellers are told to do.
Whether sequence changes go through the same release process as solution components, or are treated as business configuration owned by sales operations.

Gotchas

Old versions keep running. Change the messaging, and every record connected before that change carries on with the old messaging until it finishes. Clients almost always assume the opposite.
There is no bulk "move everyone to the latest version". If a change is compliance-driven, disconnecting and reconnecting affected records is the practical answer, and it resets their position in the cadence.
Copies don't inherit. A fix applied to the original has to be applied to every fork by hand, which is how organisations end up with eleven slightly different versions of the same call cadence.
Some settings force you out of the active state anyway, so "no downtime" isn't universal. Check what you're changing before promising an uninterrupted edit.
The version history is per sequence and not especially prominent. Nobody finds it unless they're shown, so a badly described version is effectively an undocumented change.
Assigning a sequence to a user or team gives them edit and delete rights, so production change control depends on who holds those assignments, not just on security roles.

Consultant notes

Show the client the version history and the connected-records-per-version view during handover. It's the thing that makes them comfortable changing cadences themselves, which is the outcome you want.
Make the change description mandatory by convention and audit it occasionally. It costs nothing and it's the only history anyone will ever read.
Set the expectation early that edits don't reach in-flight records. Getting this wrong once in production is a credibility hit that's hard to recover.
Agree who signs off a version publish before go-live. Treat it as a production change even though it doesn't feel like one.
Before any significant edit, take a copy as a rollback point. Reverting a version isn't a one-click operation and a snapshot costs you nothing but a slot in the list.

Worth another look if version rollback or a bulk migration of in-flight records to the latest version ever ships.