- The organization is the unit of work. Everything about a client lives inside it: domains, provider, products, roles, people.
- The onboarding state is visible in the list. Unverified domains and an unconfigured provider are the reason a client cannot sign in yet.
- Search by name and by domain. A client is looked up the way they are referred to in correspondence.
Client identity & access
An enterprise identity layer inside a B2B platform. Every company is its own tenant with its own products, roles and admin.
Product overview
Identity & Access Management is the layer that lets a whole company into the platform: clients sign in with their own work accounts, and their IT admin decides who can open which product — without a single support ticket.
Our client is not a person but a company with hundreds of employees. Before IAM, someone on our side decided by hand which product to open for each of them, so onboarding a client stretched into weeks of work, one ticket per person.
Sole designer on the product: the brief was worked through with the BA and PM, while the MVP scope and what to cut from the first version I defined myself — against one criterion: the client must manage access without us. The principle behind the solution: federate identity, keep authorization — the client’s provider (Okta, Entra ID, Ping) answers “who is this person”, our IAM answers “what are they allowed to do”.
The exception that had to be designed. Not every client has a provider of their own. For those we keep the accounts on our side — the same single-field screen, the same flows — because enterprise buyers expect both paths to exist.
Scale
500
users at the start — the platform began with them
5 500
users three years later — client company employees sign in through their own provider
3 mo.
for the first version, so the scope was laid out across iterations
2
levels of administration on one set of components — our admin and the client’s admin
How it is built
How the integration is split
The client’s provider owns people, we own access. Two channels run between the sides: federation for people, and machine-to-machine for the client’s services, which never touch the provider.
What one grant is made of
One grant reads as one sentence. Remove any part and the request is denied. A user belongs to exactly one organization, and that rule keeps every screen inside the tenant.
Four steps to onboard a client
The first two steps are on our side, the next two the client does alone. No account is created in advance: just-in-time provisioning creates it at first sign-in, with access already applied.
Screens
- A domain is what binds a person to a tenant. The work email domain routes the sign-in to the right organization, so verifying domains is a mandatory step.
- The provider is connected at the same step. SAML or OIDC — from there the client’s employees sign in with their work account.
- A claimed domain is transferred, not duplicated. One domain routes sign-in to one organization — so instead of an “already exists” error the interface shows who owns it and what the transfer takes.
- Configuration errors are visible right away. While the provider does not respond, the organization stays in an onboarding state rather than “created”.
The domain already belongs to another company
One domain can route sign-in to only one organization, so it cannot simply be added twice — it is transferred with a key.
- The setup happens on two sides. Some values the client sets on their end, some we hand over — so the screen shows both what has to be sent and what has to come back.
- The integration state is part of the interface. “Not connected” → “test sign-in needed” → “connected”: the admin sees which step it stopped at, without asking anyone.
- Sending the settings to the IT contact is built into the screen. It used to be correspondence outside the system, so the step is now recorded in the log.
- A provider counts as connected once a sign-in has gone through it. Saved settings are not enough — otherwise the client would learn about a breakage from their own employees.
Connecting the provider: who does what
The integration is an exchange of settings between two systems. Until the test sign-in passes, the organization stays in an onboarding state.
- The rule belongs to the organization, not to a person. One record describes access for everyone who falls into the group — including whoever joins tomorrow.
- Recomputed at sign-in, not on save. So the screen shows not “who already has it” but what will apply: a change in the client’s directory arrives on its own.
- Roles the client maintains by hand are kept out of the automation. Without that caveat admins were not willing to switch it on — auto-assignment would overwrite their exceptions.
- Without a connected provider the rule is unavailable. There are no groups yet, so the block shows a state rather than an empty form.
How the rule fires
Every sign-in follows the same path: the client’s provider reports the groups, the rule expands them into access.
- The operator list is not invented in IAM. It comes from Hub — otherwise there would be a second definition drifting away from reality.
- An operator is part of the grant. Without it the access record is incomplete and the request is denied.
- The account is created at first sign-in. The invitation is the last step, not the first: there is no need to create a user in advance.
- Bulk operations on what the search found. Search by emails, then change access for the whole group at once.
- Deactivation is visible in the status. A deactivated employee stays in the list with their history, but without access.
- A role is a set of permissions in specific products. It does not replace or widen membership in the organization.
- Where a role applies and who holds it is visible. That answers “what changes if I touch it”.
- Unused roles are flagged. Roles with nobody assigned and no usage are material for cleanup.
- A role is created from a product, permissions and where it applies. Roles are more often created from an example, so there is a start from an existing one; permissions belong to a product, and the grant level and properties (default role, system role) are set here too.
- The second mode is the permission matrix. Roles are laid out as columns, so the difference between them reads along a row; the “only differences” filter drops matching permissions, and rows with nobody assigned or switched off are surfaced at the top.
- The log answers questions after the fact. Who granted access and when — from records, not from anyone’s memory.
- Filters by actor, object and result. Provider failures show up here as well — it is the first place to look when someone complains about signing in.
- The banner state is part of the list. Draft, scheduled, live and expired are visible at once, so there is no need to open a record to see what is showing now.
- The audience is defined with the same entities as access. Organizations and products — not a separate recipient list.
- The invitation does not create a password. It links a person to an organization; identification is done by the provider.
- Access is applied before the first sign-in. A person lands inside already holding the products and roles from the group mapping.
Problem
The platform was being assembled anew: previously every product had its own registration and its own access, and there was no single place where a client could be seen as a whole. The identity and access management tool was built from scratch for the shared platform rather than patched on top of the old schemes.
- Access lived separately in every product. The picture of a client was assembled by hand, and there were three months for the first version — so the scope had to be laid out across iterations.
Onboarding a client: before and after
The same steps, but performed by the other side: a manual service on our end becomes configuration on the client’s end.
Process
- The brief before the specs. The product was built from scratch, so the first thing to settle was what problem the new layer solves and by what criterion it counts as done.
- Going deep into the domain. Enterprise identity is a protocol: what the client’s provider does, what stays with the platform, what arrives at sign-in. Worked through it with the BA and engineering — otherwise the interface is designed on guesses.
- Three personas as a working tool. Our admin onboards a client, the client’s IT admin manages their own people, an employee simply signs in — every decision was checked against all three.
- The logic was agreed on diagrams. The model and the flows were worked through in brainstorms with the BA, engineering and PM before detailed UI: arguing architecture on a diagram is cheaper than on built screens.
- Technical decisions were made by the BA and engineering. My part was to understand them deeply and bring back a solution that makes sense to whoever uses it.
- Testing prototypes with users. What reads as expected, and where a wording or the order of steps leads to a mistake.
- Versioning against three months. The base holds what the client cannot manage access without; the rest was moved to later iterations deliberately, not by whatever time was left.
Solutions
- One sign-in for every product on the platform. Federation with the client’s provider: passwords and MFA stay on their side, access to all connected products sits in one place.
- Self-service for the client’s IT admin. Provider, domains, groups, invitations and roles — entirely on their side.
- Manual work was replaced by a rule, not relocated. Per-person setup by hand remained only for exceptions.
- Tenant boundaries are held by the model, not by the admin’s attention. A user belongs to one organization, and that rule keeps every screen within it; our internal admin and the client’s admin work on one set of components, only the scope of visibility differs.
- The scope was laid out across versions to fit three months. The first version took what the client cannot manage access without: organizations, federation, group mapping, invitations, roles. M2M applications, the extended log and finer settings came in later iterations.
Results
Access stopped being a manual service on our side — here is what changed for the people who use it.
01
The client manages access themselves
The company’s IT admin connects the provider, hands over groups, invites people and changes their access — without coming to our support.
02
Onboarding without a ticket per person
The rule expands the client’s groups into products and roles, and the account is created at first sign-in — the manual steps on our side left the flow.
03
One sign-in instead of registration in every product
An employee signs in with their work account, passwords and MFA stay with the company, and all of their access is visible in one place.
04
The first version in three months
The scope was laid out across iterations: the base took what the client cannot manage access without — the platform grew from 500 to 5,500 users over three years.
Collaboration
- Product manager
Held the business priority — the MVP line was drawn along it: from my side came the flows and the cost of each option, and the scope was cut against that priority — SCIM and the role builder were deferred deliberately. The design part of planning and presenting solutions to stakeholders was mine.
- Business analyst
The de facto product owner and the main partner on the solution. The technical side of identity sat with him: how Okta, Entra ID and other providers behave, SAML and OIDC exchanges, which claims and groups come back, where a provider departs from the spec. His mechanics turned into screens and states, then the flows were walked back step by step — what the system can know at each point and what it cannot. That is where the single-field sign-in, the group-to-role mapping and the exception roles come from.
- Engineers
Every flow was walked through with the team before the sprint — including empty states, loading, errors, stale links and repeat sign-in. Where the identity stack made a solution expensive, the design changed; where it opened up a possibility, that possibility was requested. Design QA on the build at the end of the sprint.
- QA
Received the scenarios and edge cases built into the design: someone else’s domain, a revoked group, a deactivated account, an expired invitation — so that testing covered the intent, not just the happy path. Their findings came back into interface details: error texts, states, dead ends.
Next project
Atlas