Designing a Safe & Seamless Sandbox → Production Promotion System
When I joined the Sandbox Promotion initiative, it became clear that the real challenge wasn’t moving configurations — it was rebuilding trust in the entire change-management lifecycle. Customers described promotions as unpredictable, risky, and confusing, with inconsistent terminology and hidden failure points.
My work focused on designing a predictable, transparent lifecycle that gave teams confidence when promoting changes from sandbox to production.
Principal Product Designer
July 2024- Dec 2024
PM, Engineering, Content
Web
Why This Problem Was Critical
Across interviews with Gore-Tex, ConocoPhillips, IKEA, John Deere, and Nvidia, customers repeatedly described the same pain: promotions felt fragile and unclear.
Quotes from research showed the depth of frustration:
“Push… that hurts my head.” – ConocoPhillips
“Promote is old days. Deploy feels like real production language.” – Gore-Tex
“Tell me what will break before I break it.” – Nvidia
Promotion failures created:
hours of rework
inconsistent production environments
missing dependencies
lost change tracking
governance teams blind to unapproved changes
This fear of breakage slowed adoption, slowed experimentation, and slowed delivery.
The Insight That Pivoted Our Direction
1. Terminology was confusing
Terms like push, pull, promote, deploy, outbound had different meanings for different users.
Customers needed a single, consistent mental model.
2. Validation needed to happen early
Every customer wanted to know what would break — before requesting approval.
3. Approvals were essential
Every customer asked for approvals, role clarity, and traceability of who changed what and why.
4. Versioning and diff were universally requested
Teams hacked their own versioning systems because the product didn’t offer one.
These insights shaped every part of the final lifecycle.
My Design Approach
I redesigned the entire experience around a clear lifecycle:
Sandbox → Change Request → Validation → Approval → Deployment → Audit
My contributions focused on:
Building a predictable mental model
Change Requests as units of work
Dependencies and validation as first-class concepts
Clear before/after diffing
Immutable version history
Making validation protective, not punitive
Early sandbox-level checks
Explicit warnings vs. blockers
Inline help and explanations
Designing approvals for real governance
Module-based reviewers
Clear role permissions
Comments and reasons for approval/rejection
Making promotion feel safe
Contextual “what will happen” summaries
Confirmation patterns
Clear language: “Deploy to Production,” not “Push”
The Experience We Built
The final workflow allows users to:
See all sandbox changes
Package them into a Change Request
Validate dependencies and conflicts
Request approvals
Deploy confidently to production
Track everything through audit history
Nothing is hidden.
Nothing is assumed.
Everything is explainable.
What Changed for Customers
Before
Hidden failures
GUID mismatches
Broken imports
No approvals
No visibility
High stress
After
Single structured workflow
Automatic dependency detection
Formal approvals
Early validation
Clean diffs and versioning
Trusted audit trails
Dramatic reduction in rework
A sense of control
Impact & Business Value
Measurable outcomes
Aligned with KPIs:
Targeting 80%+ successful deployments
Reduction in reliance on bulk import/export
Fewer production environment inconsistencies
Faster onboarding for complex modules
Long-term value
Strengthens the OneTrust governance ecosystem
Improves customer satisfaction and trust
Decreases support load
Makes implementations safer and more scalable
Brings OneTrust closer to a true “sandbox-first” philosophy
This wasn’t just solving a pain point —
it was correcting a foundational gap in how customers roll out changes.