Skip to main content

Versioning & Modular Design

Every time you publish a Journey, a new version is created. Understanding how versioning works helps you plan your Journeys so that updates reach participants quickly and safely.

How Journey Versioning Works​

When you publish changes to a Journey, the platform creates a new version with an incremented version number. This has a few important implications:

  • Participants already on the Journey stay on their assigned version. They will not see any changes you make after they were assigned.
  • New participants (or restarted participants) receive the latest version. Only people who start the Journey after you publish will get the updated version.
  • Changes do NOT retroactively update in-progress participants. Once a participant is on a version, that version is locked in for them.

Think of it like a printed workbook. Once you hand a workbook to a participant, you can't change the pages they already have. But the next print run will include all your edits.

Why It Works This Way​

Versioning protects the integrity of in-progress experiences:

  • Stability for participants — someone mid-way through a Journey won't have states, transitions, or content change unexpectedly beneath them.
  • Cohort consistency — all participants assigned at the same time share the same experience, which matters for group programmes and research.
  • Workflow safety — removing or renaming a state in a new version won't break the flow for participants who are currently in that state.

The most effective way to work with versioning is to keep Journeys short and modular. Instead of building one large Journey that spans an entire programme, break it into smaller, self-contained modules.

Design principles​

  • Keep each Journey to 1–2 weeks. Shorter Journeys mean version changes reach participants faster.
  • Make each Journey self-contained with a clear entry point and a clear exit point.
  • Chain Journeys together using "Start Journey" attachments on transitions. When a participant finishes one module, the transition automatically starts the next one.

Benefits​

  • Version drift is limited to the duration of each module. A 2-week module means a participant is at most 2 weeks behind the latest version, rather than months.
  • Coaches can update the next module while participants complete the current one, without affecting anyone in progress.
  • Easy to swap, reorder, or A/B test modules without rebuilding the entire programme.

Example: Modular vs Monolithic​

Consider a 12-week programme designed two different ways:

Monolithic approach — one single 12-week Journey:

  • You publish a fix in week 3.
  • Participants who started in week 1 won't see the fix until they are restarted or finish and begin the Journey again.
  • It could take up to 12 weeks for all participants to be on the latest version.

Modular approach — four 3-week Journeys chained together:

  • You publish a fix to Module 2 in week 3.
  • Participants currently in Module 1 will receive the updated Module 2 as soon as they transition into it.
  • Within 3 weeks, every active participant can be on the latest version of each module.

Tips​

tip

If you need an urgent fix to reach an in-progress participant, you can restart them on the Journey. This moves them to the latest published version. Use this sparingly, as it resets their progress within that Journey.

tip

Always test version changes with a test participant before publishing. Create a test participant, assign them the Journey, and verify the experience is correct before rolling it out.

  • Use descriptive Journey names that include the module or phase (e.g. "MoveFit — Week 1–2: Getting Started", "MoveFit — Week 3–4: Building Habits"). This makes it easy to see which module a participant is on at a glance.