Program Versioning: making live editing safe
Post Publish Program Edits was the most-requested capability in Gainsight Journey Orchestrator's history. I led the design of a copy-based versioning model that let admins edit active programs in place, safely, incrementally, and without disrupting participants mid-journey, across a multi-quarter, three-phase initiative.
Program editor in PPE Draft state, an amber banner anchors context while the active version keeps running in parallel.
Published programs were immutable, and that was expensive
Journey Orchestrator programs are complex, living systems: segments shift, priorities change, and the right engagement changes with them. Yet every published program was treated as locked. The only escape was cloning, which lost all historical analytics and disrupted active participants.
Locked participants
Adding a segment, correcting a query filter, or including a high-risk account meant cloning the program, losing analytics and disrupting journeys already in progress.
Unrepairable errors
A misconfigured branch, a wrong delay, or an outdated template couldn't be fixed without taking the program offline, forcing a choice between broken and interrupted.
No agility
Teams couldn't respond to real-time change, a renewal risk mid-program, a new launch needing a touchpoint, a CSM loop needing a Slack step. None could be accommodated.
“Ability to edit Journey Orchestrator programs”, upvoted across multiple Gainsight community threads, one of the longest-standing open feature requests in the product's history.
Three systemic questions, answered at the platform level
The tension wasn't cosmetic. Allowing edits to a live program introduces real risk for participants mid-journey, so the design had to answer three questions at once.
How do you make editing feel safe?
Admins needed confidence that editing wouldn't break the active program.
How do you communicate continuity?
Existing participants shouldn't restart, they continue from their current step in the new version.
How do you handle analytics?
When steps are added or skipped, cross-version analytics become ambiguous.
Three phases, each a complete increment
Given the technical complexity, the platform was designed and shipped in three phases, never a partial feature.
Edit mode & source filter edits
- ‘Edit’ button on active and paused programs
- Creates a draft copy, active program runs unchanged
- Modify query filters to update the participant list
- Re-publish overrides the active version; participants continue
- Execution history logs draft creation & re-publish
Add fields to sources
- Use existing source fields as tokens in edit mode
- Add new fields across Query, Segment, Data Designer, CSV, Events
- New participants synced; existing retain prior values
- Per-source rules with distinct behaviours
- Manual sync to re-sync with new fields
Edit program flow
- Insert new steps at any position (Email, Delay, Evaluate, Slack…)
- Update delays, evaluate logic, outcome wait timers
- ‘Skip step’ replaces hard deletion
- Added & skipped steps differentiated in analytics
- Publish status indicator with rollback on failure
Five decisions that made the system trustworthy
Edit as a copy, not in-place
Editing creates a copy of the active program. The live version keeps running with no interruption while admins work in a clearly labelled ‘PPE Draft’ state, a persistent amber banner reinforcing that they're editing a copy. This framing removed the biggest source of admin anxiety: fear of accidentally breaking something customers were already in.
Safety by architecture, not by warningSource editing with participant transparency
When filters change, a green confirmation surfaces exactly how many new participants will be added on re-publish, with a clear note that existing participants are unaffected. Each source type carries distinct capabilities, surfaced in context, not buried in documentation.
Skip, don't delete, preserving participant integrity
Hard-deleting a step orphans participants who already completed it and breaks analytics integrity. Instead, ‘Skip step’ keeps the step in the flow but marks it skipped for future participants. A counterintuitive but critical decision that came directly from deep collaboration with engineering on participant state management.
Cumulative analytics with version awareness
Analytics across versions is genuinely hard, added steps reach only a subset of participants; skipped steps change paths. The decision: show cumulative performance by default, with a ‘filter by publish date’ control to isolate version-specific behaviour. New and skipped steps are labelled inline.
Publish as a moment of truth, the summary modal
Re-publishing overrides a live program and transitions participants, so the design treats it as a deliberate review moment. A summary modal surfaces every change, sources, new steps, skipped steps, analytics, with an explicit continuity guarantee before confirming. This became the primary trust-building moment in the entire flow.
Publish updates · Summary of changes
Query filter updated, 42 new participants added
Slack nudge inserted after Evaluate
Email v1 marked skipped for future participants
Cumulative view enabled with version filter
From community signal to a defensible system
Community research
Read every upvoted thread on program editing. The real pain wasn't ‘I want to edit’, it was ‘I'm afraid to publish because I can't fix mistakes.’ This reframed the brief from a feature request to a confidence problem.
Requirements mapping on Miro
Mapped the full state space with PM, program state, edit type, participant state, analytics impact. This map became the source of truth for scope across all three phases.
PRD co-authoring on Coda
Contributed directly to the requirements doc, proposing the copy-based draft model, skip-not-delete, and the cumulative analytics view. Design decisions were captured before a single screen was drawn.
Figma explorations, three directions
Explored in-place editing with a lock model, a side-by-side active/draft view, and the copy-based draft with banner. Presented to PM and engineering with a trade-off matrix; copy-based won on safety and clarity.
Iterative delivery across sprints
Maintained a living Figma spec updated every sprint, joined standups during crunch, attended QA reviews, and wrote microcopy for every system state.
Scope negotiation under constraint
Adding new fields was descoped from Phase 1 mid-build for stability. I redesigned the scope communication, info banner and onboarding tooltip, to set expectations without making the feature feel incomplete.
Bug bash & QA partnership
Defined edge-case UI states for migration failures, rollback, publishing timeouts, and X-Org validation, so every failure mode had a designed response, not a raw error string.
Three phases · three sub-epics · 100+ tickets
| Category | Examples | Count |
|---|---|---|
| UI Stories | Edit mode entry, source panel, flow editor, skip step, publish modal, analytics | ~28 |
| Backend Stories | Versioning table, participant caching, worker changes, field dependencies, S3, X-Org | ~22 |
| QA Stories | Source edits, flow edits, backward compat, Redshift, X-Org, regression, migrations | ~18 |
| Automation | PPE Phase 2 automation, manual sync automation | 3 |
| Spike / POC | Backend analysis & UI flow builder POC for Phase 3 | 2 |
| Bugs | Publishing failure edge case, union mapping condition, evaluate preview | 8 |
| Tasks | UI tech analysis, PX trackers, security review, microcopy | 12 |
| Total | All categories across three sub-epics | 100+ |
Years of community demand, resolved
- Admins can now edit active programs without taking them offline, zero disruption to existing participants
- Participant continuity is guaranteed across versions: no restarts, no data loss
- Cumulative analytics with version filters tell the full story even after multiple flow changes
- Two of the highest-voted requests in the Gainsight community, editing participants and editing flow, were both closed
- Complex programs are less risky to build, directly increasing JO adoption depth
Systems thinking across four state spaces at once
This work demanded designing across participant state, version state, source type, and analytics simultaneously, and holding a single coherent mental model across 12+ months and three phases. The strategy lived in architectural decisions (copy-based drafts, skip-not-delete) made in the PRD before any screen existed, and in the cross-functional alignment that turned a years-old request into shipped platform capability.