Case Study

Governance Platform · Design deep dives

Operational workflows behind the platform.

A collection of detailed walkthroughs covering identity setup, provisioning behavior, fallback access, and teammate lifecycle management across enterprise environments.

These sections expand on the main case study with deeper workflow thinking, edge cases, and operational decisions that shaped the final platform experience.

SCIM provisioningSSO and fallback accessTeammate lifecycleBack to case study

Workflow · Provisioning

How provisioning actually moves between systems.

Identity is owned by the customer's identity provider. The platform's job is to listen to it accurately, apply the result deterministically across every workspace, and keep that loop legible to the admin — through token rotation, role mapping, and sync failures.

01 · Source

Identity provider· Source of truth

Source

IdP directory

Users, groups, attributes — owned by the enterprise's identity team.

Source

Group membership

Reflects organisational structure; downstream role mapping reads from here.

Source

Identity audit

Joiner / mover / leaver events originate at the IdP; the platform observes.

SCIM 2.0

Token-authenticated, push-mode

02 · Orchestration

SCIM module· Platform-managed

Service

Token issuance

Bearer tokens scoped per tenant. Rotation is visible — never hidden behind a regenerate button alone.

Tenant-scoped

Service

Sync engine

Reconciles incoming SCIM operations against tenant state; back-pressure on bursts.

Idempotent · ordered

Service

Role mapping rules

IdP groups → platform roles, with explicit precedence so two rules never silently disagree.

Service

Retry & reconcile

Failed operations queue with a bounded retry window; reconciliation runs on a quiet schedule.

Bounded retries

State

Lifecycle states

Managed · Unmanaged · Guest · Temporary. Each row knows which one applies.

Audit

Audit trail

Every reconcile, mapping change, and token event becomes a row in the audit log.

Outbound sync

Tenant-scoped, observable

03 · Tenants

Workspaces· Enterprise destinations

Tenant

Workspace · A

Region: NA · SCIM on

Tenant

Workspace · B

Region: EU · SCIM on

Tenant

Workspace · C

Region: APAC · SCIM on

Tenant

+ N tenants

Each workspace inherits the orchestration contract above.

The platform doesn't own identity. It listens to identity that lives somewhere else — and the design has to make that asymmetry obvious at every step, not just on the day setup happens.

Screens · Provisioning

What admins actually see, in product.

The role-mapping surface, the conflict-prevention model behind it, and the state-aware messaging that turns setup into an ongoing system the admin can trust.

— 01Role mapping

The centrepiece of SCIM administration: IdP groups mapped to platform roles, with precedence held explicit so two rules can never silently disagree.

SCIM role mapping — IdP groups assigned to platform roles with explicit precedence.
The shipped role-mapping surface. Each row pairs an IdP group with a platform role; precedence is a property of the rule, not an assumption about the order.
— 02Mapping at scale

Two adjacent surfaces that keep role mapping coherent as the enterprise grows — explicit conflict prevention and a small set of well-named role abstractions.

Role mapping conflict — the surface naming and resolving an overlap between two mapping rules.
Conflict prevention. When two rules overlap, the conflict is named on the surface — not buried in a tooltip.
Role mapping variants — exploration of role abstractions used to keep the mapping surface readable at enterprise scale.
Role abstraction exploration. A small set of named roles keeps the mapping page legible across hundreds of IdP groups.
— 03Operational state inside setup

Setup completion isn't the same as system health. These two surfaces turn the SCIM configuration page into a page that also reports on itself.

SCIM operational states — the four observable conditions of a SCIM connection, surfaced inline on the setup page.
The four observable conditions of a SCIM connection — configured, syncing, drifted, errored — surfaced inline on the page that configured them.
SCIM state-wise messages — the operational guidance shown for each connection state.
State-wise guidance. Each operational condition carries a short, specific recovery message — not a generic error.

Workflow · SSO and fallback access

What happens when the identity provider isn't reachable.

Most days, single sign-on works. On the day it doesn't — a certificate expires, an IdP outage hits, a misconfiguration lands — the admin still needs to get into the platform. This workflow shows the primary sign-in path, the two narrow fallback paths beside it, and the recovery loop that returns the system to SSO as soon as it can.

00 · Entry

Admin sign-in· Single surface

Source

Admin opens admin URL

No fork in the URL itself — the same address handles both paths.

Service

Tenant lookup

Tenant resolved from the email domain or workspace hint.

Service

Auth router

Reads tenant SSO posture; decides which path to surface next.

State-driven

Authentication state

IdP available

IdP unavailable

01a · Primary

SSO· Happy path

Service

Metadata exchange

IdP metadata parsed; entity ID, ACS URL, and certificate read inline.

Service

SAML / OIDC handshake

Assertion validated against the configured signing certificate.

State

Certificate state

Healthy · Near-expiry · Expired — surfaced before the admin is locked out.

Pre-emptive

State

Session issued

Standard session, scoped to tenant, observed in the audit log.

01b · Fallback

Break-glass user· Always discoverable

Fallback

BGU credential

Local credential held by a small set of named admins; never federated.

Fallback

Sync-exempt flag

The BGU account is immutable by SCIM. A failed sync can't disable the door.

Immutable property

Fallback

Hard ceiling

A tenant cannot have more than N break-glass users at a time.

Audit

Audit notification

Every BGU login pings the other admins — resilience without observability is just risk in a different jacket.

On every login

Recovery

Time-bounded continuity

02 · Recovery

Return to primary· Lifecycle-bounded

State

Temporary continuity

BGU session is time-bounded by policy; expiry is visible to the admin.

Time-bound

Service

IdP health check

Platform polls the identity provider; restoration is observed automatically.

State

Return to SSO

When SSO is healthy, the next sign-in goes through the primary path again — the door closes itself.

Fallback access isn't a separate feature. It's the same authentication surface, with two narrow paths that stay available without being advertised — and an audit trail that makes sure no quiet entry is actually quiet.

Screens · SSO and fallback access

The sign-in path, walked end to end.

Six screens, in the order the system uses them — the canonical SSO sign-in, the domain identifier that routes the request, the two fallback paths, the metadata-aware setup surface, and the configuration summary the admin returns to.

— 01Direct SSO sign-in

The happy path. The default surface every admin sees first — the system assumes the identity provider is available.

Direct SSO sign-in — the canonical authentication surface.
Direct SSO sign-in. The default state of the page when the identity provider is reachable.
— 02Path selection

The domain identifier — the small surface that decides whether the request continues on SSO or routes to a fallback path.

Domain identified — SSO path. The system recognises the domain and continues on the SSO route.
When the domain is identified and SSO is healthy, the system continues without surfacing the fallback at all.
— 03The two fallbacks

When SSO can't complete, the surface routes the request along one of two narrowly-scoped paths. Both stay available without being advertised.

Domain identified — break-glass user (emergency access). The fallback for when the identity provider is unavailable.
Emergency break-glass. Bounded, audited, surfaced only when the IdP is unreachable.
Domain identified — break-glass user (active temporary teammate). The fallback for active temporary access continuity.
Active temporary teammate. A second, narrower fallback that handles in-flight temporary access without forcing a full SSO trip.
— 04Setup · Metadata handling

The setup page treats the IdP metadata as parseable input — not as a blob the admin has to translate. Errors are named, not generic.

SSO metadata handling — parsed IdP metadata with the relevant fields surfaced inline.
Metadata is parsed and the relevant fields are surfaced inline. The admin reviews their IdP rather than translating it.
— 05Configuration summary

The page the admin returns to after setup. The same surface that configured the integration now reports on its own state.

SSO configuration summary — the four observable conditions of an SSO connection surfaced inline on the setup page.
The four observable conditions of an SSO connection are surfaced on the same page that configured them. Setup completion isn't pretended to be the end of the work.

Workflow · Teammate lifecycle

The years after someone is invited.

Most of the operational risk in an enterprise account doesn't sit in the moment a teammate is invited — it sits in the years after. Six named states, the transitions between them, and three rules that stay true across all of them. The interface gets simpler because every row already knows what it is.

  1. State · 01

    Invited

    Pending acceptance, scoped to a tenant.

  2. State · 02

    Active

    Full member. Managed or unmanaged is decided by source of truth.

  3. State · 03

    Guest

    External collaborator. Reduced surface, named owner inside the tenant.

  4. State · 04

    Temporary

    Time-bounded session with an explicit expiry surfaced to the admin.

  5. State · 05

    Inactive

    No recent sign-in. Visible in the operational table, not deleted.

  6. State · 06

    Archived

    Retained for audit. Access removed; identity preserved for accountability.

Lifecycle is the part of governance admins live with longest, and that gets the least design attention. Naming the states explicitly meant the interface could finally answer the questions the configuration page never asked.

Screens · Teammate lifecycle

What the lifecycle looks like in product.

The states named in the workflow are operated through four surfaces — the teammates view, validity handling for time-bounded access, distinct member and guest invite paths, and the domain-policy constraints that gate invitation.

— 01Teammates view

The lifecycle, surfaced. Every row carries the state it is in — managed, guest, temporary, inactive — and the action menu adapts to the row, not the page.

Teammates view — the lifecycle table with state indicators per row.
The teammates view. Lifecycle state is a column, not a setting — so an admin can see who is who without opening a single drawer.
— 02Validity handling

Temporary access modelled as a property of the row, not a separate page. Expiry is visible, editable, and reads as part of the lifecycle — not as an afterthought.

Teammates validity handling — temporary access expiry surfaced per row.
Validity is a first-class property of the row. Time-bounded access has a visible end date, not a calendar reminder elsewhere.
— 03Distinct invite paths

Members and guests enter the lifecycle through deliberately separate surfaces — same component shell, different defaults, different governance rules.

Add teammates — Members tab. The invite path for full members.
Member invite. Full-access path; defaults are deliberate.
Add teammates — Guests tab. The invite path for time-bounded guest access.
Guest invite. Time-bounded by default; lifecycle constraints inherited.
— 04Invitation constraints

Domain policy enforced on the invite surface, named explicitly. The error message tells the admin which rule fired — not just that something failed.

Teammate invitation error — outside-domain address blocked at the invite step.
Outside-domain block. The constraint is named, not generic.
Teammate invitation error — non-whitelisted domain blocked at the invite step.
Non-whitelisted-domain block. Distinct from the outside-domain case, on purpose.

End of deep dive

Back to the case study