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. It was developed as part of the broader Journey Orchestrator transformation.
Program editor in Post Publish Edit 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.
The strategy lived here, not in the UI
Before a single screen, I mapped the full lifecycle, what a program is at each stage, and every transition between them. The hard decisions in this project were made on this canvas, in the PRD, before design started.
The program lifecycle, designing the states and transitions before designing screens.
Three problems the model had to solve
We first looked at letting admins edit the live program directly. Engineering discussions made the risk clear: editing an active program can corrupt participant state and leave cross-version analytics ambiguous. That moved us toward a copy-based draft model, and the design still 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 for drafts
ShippedEnable safe, in-place edits to a draft copy while the live program continues running.
Key capabilities
- Create draft from live
- Edit email, wait, logic steps
- Post Publish Edit Draft banner & state
- Publish draft to replace live
~40% reduction in clone usage
Edit source fields & properties
ShippedAllow updates to source fields, filters, and properties without rebuilding the program.
Key capabilities
- Add / remove source fields
- Update filters & mappings
- Preview impact before publish
- Version history & comparisons
~60% faster source updates
Edit program flow
ShippedEnable structural flow edits, add actions, connect branches, skip steps, without breaking continuity.
Key capabilities
- Insert new steps in flow
- Connect / re-route branches
- Skip (not delete) any step
- Full versioning & history
Safe edits at scale, confidently
Key decisions in the versioning model
Source 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.
Steps are skipped, not deleted
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.
A publish summary before anything goes live
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
Designing the versioning model
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.
State-space architecture
Trade-off matrix, three explored directions
The platform model was chosen before UI exploration, ensuring every interaction reinforced safety, continuity and analytics integrity.
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 | Post Publish Edit 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+ scoped |
The edited flow, end to end
The shipped experience, end to end, generating a safe draft, inserting and re-routing steps, and validating every branch before publish.
A long-requested capability, shipped
- 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
Designing 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.