— 01
Owned by no one in particular.
Each governance surface — SSO, SCIM, roles, audit — had a different team behind it. Decisions made sense locally, then collided in the admin’s actual workflow.
Enterprise platform design · Case study
Governance Infrastructure for Enterprise-Scale SaaS Administration.
Designing governance systems that simplify identity, access, lifecycle management, and operational administration across enterprise-scale SaaS environments.
The study traces how separate administrative surfaces — single sign-on, provisioning, break-glass access, and teammate lifecycle — were brought into a single, coherent governance layer.
- Discipline
- Enterprise platform design
- Scope
- SSO · SCIM · Lifecycle · Governance
- Audience
- Enterprise admins, IT, security
- Read time
- ≈ 8 minutes
01 · The problem
The growing governance problem.
Governance, in most SaaS platforms, doesn’t arrive as a feature. It accumulates — one admin setting at a time, owned by whichever team needed it most that quarter.
By the time enterprise customers started arriving with thousands of users across multiple workspaces, the platform had grown a governance footprint without ever having been designed as one. Identity lived in one corner, provisioning in another, roles in a third, and audit somewhere beneath them all.
From the outside, it looked like a configuration problem. From the inside, it was something larger: a coordination problem dressed as a UI problem.
“Most enterprise tools don’t have a governance experience — they have a settings page that grew up.”
— 02
Designed for setup, not for living with it.
Most flows assumed a one-time configuration. The reality was the opposite: certificates expired, tokens rotated, teams reorganized, and the same screens were visited for years.
— 03
No single operational view.
Admins couldn’t answer simple questions — who has access to what, across which workspace, configured by whom — without piecing it together across half a dozen places.
Flow A · The shape of the problem
Disconnected admin tools
Per-team ownership, drift over time
Growing enterprise complexity
Multi-workspace, federated identity
Operational friction
Repeated questions, no single view
Centralized governance
One model, one operational surface
02 · Signals
What enterprise customers were actually asking for.
The asks rarely came as design briefs. They came as questions in security reviews, footnotes in procurement, and increasingly urgent emails from IT admins running the platform inside their own organizations.
Read together, the same three shapes kept appearing — across pharma, financial services, global retailers, and enterprise software companies with their own multi-region footprints. Not features. Operational expectations.
Signal · AIdentity at scale Federate identity across every workspace — without re-explaining the policy.
Customers expanded across regions and business units. They expected one identity policy to apply consistently, without re-implementing SSO per workspace or maintaining sixteen variants of the same role mapping.
“We can’t run the same SSO setup conversation six times in one quarter.” — Director of IT, global pharma
Signal · BLifecycle, not setup Treat provisioning as a living system, not a one-time form.
Tokens rotated, certs expired, employees left, and admins changed. The product needed to handle the months and years after setup — not just the afternoon it was first configured.
“Tell me what’s changing, where, and when — that’s the actual job.” — Security ops lead, enterprise software
Signal · COperational visibility Show me one view I can run governance from.
Repeatedly: the same request. Stop making admins click through fifteen screens to answer one audit question. Give them a place where access, identity, and lifecycle are visible together.
“I just want a page I can open on a Monday morning.” — Platform administrator, financial services
By the time we sat down to plan the next platform cycle, these weren’t edge cases. They were the operational reality of the customers we were already serving — and the ones about to land. Governance had to become a product surface, not a configuration page.
Industries shaping these signals
- Pharma
- Financial services
- Global retail
- Enterprise software
03 · Identity & Access
Simplifying identity and access — without simplifying it away.
SSO and SCIM had each been built as separate features, by separate teams, at separate times. The redesign treated them as one identity surface, and asked a quieter question: what does an admin actually need to know, and when?
A · Single sign-on setup
Make the setup the truth — not a translation of it.
The old SSO form asked admins to translate their identity provider into a series of inputs, then guess whether the translation was correct. The redesign reads the metadata, parses the certificate, names the state, and only then asks for input.
The screen looks calmer because it does more before it asks anything.
B · Provisioning, as a lifecycle
Design the years after setup, not just the afternoon of it.
SCIM is rarely a single moment. It’s a token that has to be regenerated, a workspace list that grows, a role mapping that drifts, and a sync that can quietly fail at three in the morning. The design had to be legible at every one of those moments.
The decision underneath all of it: keep one source of truth at a time. Manual paths close cleanly when SCIM is active. They reopen, just as cleanly, when it’s not.
Flow B · Identity, end to end
Identity provider
IdP as the source of truth
SSO setup
Metadata read, state named
SCIM provisioning
Tokens, sync, edge states
Role mapping
Explicit precedence per rule
Operational lifecycle
Drift, audit, recovery
04 · Resilience & Lifecycle
Designing for the day SSO doesn’t work — and the years after it does.
Once identity was federated, the design problem moved. It became less about how people get in, and more about what happens when they can’t — and what happens to them, slowly, over time.
A · Break-glass access
A quiet door, never marketed — but always there.
The first design constraint was simple: the platform must remain administrable when the identity provider isn’t. That meant a fallback path that is discoverable, not visible — and a class of user that survives a SCIM sync gone wrong.
Every break-glass login notifies the other admins. Resilience without observability is just risk in a different jacket.
B · Teammate lifecycle
One table, four kinds of teammate, one set of rules.
The teammates surface had quietly grown into the most-used screen in the platform’s admin area. The redesign treats every member as a lifecycle object — managed, unmanaged, guest, or temporary — and lets the same actions read consistently across the four states.
When SCIM is on, certain rows become read-only; the source of truth is named at the row, not buried in a global mode switch.
Flow C · How resilience is paid for
SSO unavailable
IdP outage, cert expiry, misconfig
Break-glass access
Discoverable fallback, sync-exempt
Temporary continuity
Time-bounded, audit-notified
Lifecycle recovery
Return to IdP, close the door
05 · Centralized governance
What started as separate features became one operational surface.
Each redesigned surface had quietly been built to feed the same model — workspaces, identities, roles, lifecycle. With those shared underneath, the dashboard wasn’t a new feature so much as a long-overdue consequence.
The Monday-morning view
One place to open. One place to scan. One place to act.
The governance dashboard is the screen an admin should be able to keep open all day and trust. It shows the workspaces under their care, the identity posture of each, anything that needs attention, and one clear next action.
It is, deliberately, not an analytics page. It is an operational page that happens to summarize.
Flow D · What the surface brings together
Workspaces
The unit of governance
Identity
SSO posture, cert state
Teammates
Roles, ownership, lifecycle
Auditability
What changed, when, by whom
Operational visibility
One view, ready on Monday
“The dashboard isn’t a new product. It’s what the existing products look like when they finally know about each other.”
06 · Reflection
What the work changed — and what I learned.
The most useful outcomes weren’t the screens. They were the shifts underneath — in how the team described governance, what we considered a design surface, and what we were willing to leave alone.
What follows isn’t a metrics page. Numbers in this space are usually proxies for comfort. The honest signal is whether enterprise customers stopped having to ask the same questions every quarter — and increasingly, they did.
- — 01A shared language for governance.
- Identity, access, lifecycle, and audit stopped being four roadmaps and started being one set of nouns the team — design, engineering, security — agreed on.
- — 02Setup that survives the rest of the year.
- SSO and SCIM stopped requiring re-implementation across every new workspace. Onboarding a new enterprise stopped feeling bespoke.
- — 03Operational visibility, not analytics.
- The dashboard isn’t a charts page; it’s where admins start their morning. The signal in it is operational — what needs attention, what changed, what’s safe to ignore.
- — 04Resilience as a design constraint.
- Break-glass access, SCIM-immune flags, audit notifications, and time-bounded sessions stopped being features and started being part of the platform’s default posture.
In closing
Enterprise governance design rarely rewards velocity. It rewards patience — the willingness to wait for a coherent system to be possible before drawing the screen that depends on it. The work I’m proudest of in this project isn’t any single surface; it’s that, by the end, the surfaces had started behaving like a platform.
— Pratik Raj