Journey version history

Every time you Publish a journey, PeakCommerce saves a snapshot of it. Those snapshots are the journey's version history — and each one records not just what the journey looked like, but what changed since the version before it, so you can review, compare, and roll back with confidence.

View versions

Open the journey (Content → Journeys → View) and select the History tab. Each entry is a published version, newest first. Until a journey has been published, the tab shows "No versions yet — publish the journey to create the first version."

Each version row shows:

• The version number and its status badge — Published (live), Draft, or Archived (superseded).

• When it was published or created, how many steps it had, and who published it.

• A one-line change summary against the previous version — e.g. +1 step · 2 steps changed · 3 actions. The summary covers journey metadata (name, type, description, order structure), steps added / removed / renamed / reordered, and per-step commerce-action changes — so you can scan the history and spot the version that introduced a change without opening anything.

Compare versions

Click View on a version to expand it. Above the full snapshot, a "Changes from v N" panel shows the color-coded diff against the immediately preceding version:

• + (green) — additions, e.g. Added step "Confirm" or + action added (create_order).

• − (red) — removals.

• ~ (amber) — modifications, with nested detail lines drilling into exactly what moved: a step renamed or repositioned, its branching or variables changed, and each commerce action's field-level changes (operation, execution mode, run order, field mapping, conditions, response outputs, and more).

The first version shows "Initial version" — there is nothing before it to compare against. Below the diff, the panel lists the version's full snapshot: name, type, description, and every step with its action count.

Restore a version

Archived versions carry a Restore button (you need permission to update journeys). Restoring is deliberately non-destructive to what's live:

• It copies that version's configuration into a new draft, replacing the journey's current working steps and actions.

• The live published version is untouched — customers keep seeing the current journey until you review the restored draft and publish it.

• Any unpublished draft edits you had are archived (they remain in the history).

A confirmation dialog spells this out before anything happens — Restore as draft confirms, Cancel backs out. After restoring, review the draft on the Steps tab and publish when you're satisfied; publishing creates the next version as usual.

Why it matters

• Recover a known-good state — a published version is a restore point if a later edit causes a problem, and Restore gets you back to it without touching what's live until you're ready.

• Track what went live and when — versions are created at publish time, so the history reflects what customers actually saw, and each version's diff shows what changed between publishes.

Looking for who changed what — actor, timestamp, and field-level changes? That activity is recorded in the platform audit log (Reporting & Analytics → Audit Trail & Logs), separate from journey version history.