Approval Route Management

The Opportunity

The Decision That Changed Everything

We looked at how our enterprise base was actually using the platform, and standardized on Mandatory Upward Propagation (MUP) rather than continuing to support both models (MUP and Non-MUP):

• MUP matched how nearly 60% of enterprise clients already operated, so most customers needed no behavior change at all.
• We supported single-tier approval within the MUP model, so organizations with simpler structures weren't forced into complexity they didn't need.
• We expanded the approval tier limit from 3 to 10: user data surfaced orgs with as many as 7 tiers in a single route, and capping lower would have forced workarounds, affecting a smooth migration to the new model.
• Ensured that in-flight requests were not affected by the migration, so ordering could proceed with ease.
• De-coupled PO creation from approval requests, which reduced friction for our customer as the PO was only created when the order was ultimately placed.

The trade-off: short-term migration complexity for a system customers could trust long-term.

Click to enlarge

With MUP, every request climbs through all applicable tiers regardless of amount. Without it, a request only needs approval at the tier matching its value, skipping the rest. Orders under $5,000 are automatically approved, regardless of model.

Design

I designed distinct experiences for admins, approvers, and requesters, each one providing much-needed autonomy and transparency into the approvals process.

Admin view

Create and manage approval routes, assign multiple approvers per tier, and manage users with more flexibility.

Approver view

Full visibility into request status, with item-level approve/reject so one flagged item doesn't hold up an entire order.

Requester view

Clear status at every step, including exactly which approver rejected an item and why.

Behind the Decisions

The hardest part wasn't any single decision, it was figuring out which edge cases genuinely belonged in the initial release. Nearly every scenario Customer Success and Operations surfaced seemed important, and separating real customer risk from nice-to-have coverage took constant negotiation between customer value, engineering effort, and long-term scalability. One trade-off I made deliberately: I simplified version history down to a "last edited by" record for the MVP rather than building a full audit log, which let us ship the core model faster without losing accountability entirely.

Throughout, my role went beyond design execution. I partnered closely with the PM to help shape product strategy, facilitated alignment across Product, Engineering, Customer Success, and Operations, and made sure we were consistently solving the right problem rather than just responding to the loudest feature request.

Outcomes

• 97% adoption within two months of GA.
• Customer Success ticket volume dropped substantially.
• Approval Route Management now runs approvals for every enterprise account on the platform, with zero ongoing dependency on Customer Success.

Reflections

Designing a system that balanced enterprise flexibility, engineering feasibility, and long-term scalability, instead of optimizing for only one of those dimensions, was challenging but ultimately rewarding. The project was an exercise in UX & product decision-making more than pure interface design.

Next Steps

Phase 2 builds directly on this foundation: rescue flows for when an assigned approver is unavailable or has left the org, and item-level mapping to expenditure groups (GL account, cost center, project code) for more streamlined financial reporting. Both were designed for from the start, so the tier structure and MUP model we shipped can support them without further architecture rework.