Bringing access under one roof

At a glance

Role

Lead designer for the access-management domain of a multi-tenant SaaS console, where enterprise customers manage the software they buy.

Problem

A new account architecture broke the old identity model. To answer "what can this person reach?", an administrator had to open every user in turn. Nobody could look at a resource and see who had access to it.

What I did

Flipped the model from identities to resources, so access reads in both directions. Then built a role-creation framework that holds a simple product and a composite of many products in the same pattern.

Outcome

Three enterprise products adopted it as a shared capability rather than building their own. Auditing access went from one user at a time to a single view.

The honest part

The real problem was not in my domain. Users could not understand access management because they had never understood the console. Fixing that meant going upstream into onboarding, which belonged to other teams.

The setup

The console is where enterprise customers manage what they have bought. Their account, their subscriptions, the running product instances, and the people allowed to touch any of it. I led design for access management, which covers users, groups, API keys, service IDs, and the roles that grant them access.

This case study is about rebuilding that domain. It is also about a problem that turned out to live somewhere else entirely.

The trigger

This was not a polish pass. The platform forced it.

A new version of the console introduced accounts as real boundaries. An account is a self-contained space with its own subscriptions, its own running instances, and its own identity provider. That last part matters. Each account now had its own separate pool of users.

The old identity model could not express that. Users and groups floated in flat, global pools, sitting loosely beside the things they could reach. To answer a question as basic as “what can this person access?”, an administrator had to open each user and trace their roles one resource at a time. And it only ran one direction. There was no way to look at a resource and see who could reach it. Access existed. Visibility did not.

Visual coming

Turning the model around

The fix was to stop starting from people and start from things.

Instead of browsing pools of users and reverse-engineering what each one could touch, an administrator opens a resource and sees exactly who holds a role on it. The relationship reads both ways. Start from a user and see their resources, or start from a resource and see its users.

That is easy to say. The hard part was not the screens. It was a word.

”Resource” meant two different things

Reorganizing around resources only works if people know what a resource is. Ours were not one thing. They were two, and they carried completely different kinds of access.

Console assets are the account and its subscriptions. The roles on them govern the platform itself. Who administers the account. Who manages the plan you pay for.

Product instances are the actual running software your subscription entitles you to deploy. They carry their own roles, about who can use or administer that software.

One person could administer the account and have no access at all to a running instance. Another could live inside an instance every day with no account rights whatsoever. Users conflated the two constantly, because in their heads it was all just their stuff.

The wall was not where I thought it was

I spent a long time trying to make this legible inside the access-management screens. Nothing worked. Then the research told me why.

Users did not understand what the console was for. They had bought a product. They expected to go and use it. Instead they were handed a management layer sitting between them and the thing they actually wanted, and I was asking them to learn its architecture, accounts and subscriptions and instances and two kinds of roles, to do a job that felt beside the point.

So the problem was never “make the word resource clearer.” The problem was that access management was the first place a user met the platform’s architecture, and by then it was far too late.

Fixing it upstream

The fix belonged in onboarding, so the mental model would already be there by the time anyone reached my screens. Onboarding was not my domain. I drove the change anyway, working with the product managers and designers who owned it. Four moves:

1. Autoprovisioned setup wherever a product supported it, collapsing the steps between buying and running.
2. One meaning for “account.” Several systems used the word to mean slightly different things. We settled on one.
3. A clear line between the product and the console. The main path takes you straight to the product you just bought. The console is framed for what it actually is, the place you manage your subscription, your account, and your users. You can step into it now or come back to it later from the product.
4. The tour, replaced. A heavy guided tour that most people skipped became dismissible, in-context touchpoints that make their point in the moment.

Access management stopped being where users first met the architecture. They arrived already knowing what a resource was. “Go to a resource and give someone a role on it” finally made sense.

Visual coming

Role creation, across twenty products

The second hard problem was data, not screens.

More than twenty product teams use this console. Customers needed roles shaped to their own organizations, not just the six fixed roles the console ships with. So products had to expose their own roles up into the console, where an administrator could tailor them and assign them.

Those role models are nowhere near comparable. I needed one pattern consistent enough to feel like a single system, and flexible enough to hold products that look nothing like each other.

First attempt, and why it failed

I underestimated the scale some of these products run at. The simple ones are a tidy list of roles and permissions. Many are products of products, composites with dozens of sub-products, each carrying its own roles and permissions.

My first model was a flat list. Browse every permission, check the ones you want, assemble a role. It failed twice over. It did not scale, because a flat list drowns under a large composite product. It did not cohere, because the permissions someone checked did not necessarily work together, so you could build a role that made no sense. Total freedom produced broken roles at a scale nobody could navigate.

What worked

Two decisions, each answering one half of that failure.

Start from something that already works. Rather than building a role from an empty list, the first step lets an administrator start from scratch or clone an existing role. Cloning pulls in a known-good set of permissions as a foundation to adjust. You begin from coherence and modify, instead of assembling coherence from nothing.

Let the products define the structure. Working with the product teams, we organized permissions into categories that each product owns. The depth varies. For a simple product, the role is the category. For a composite, the categories are whatever that product finds meaningful, things like administrative actions or API calls. The console renders permissions by category no matter how complex the product is.

That is a contract. The product teams define their categories. The console owns the rendering and the administrator’s experience. The next product to arrive needs no redesign.

Visual coming

Also delivered in this work, briefly. Support for both role-based and attribute-based access control, made legible to administrators who do not think in policy models. And self-service identity-provider setup, which turned per-account federation from a brutal configuration task into something an administrator can do alone.

Measuring a middle layer

A note on metrics, because being straight about them matters more than inflating them.

This console is a middle layer. Its users are both the products that plug into it and the customers who buy those products. Top-line numbers like user growth ride on product sales I do not control. Claiming them would not be honest. Here is what is.

• Three enterprise products adopted this as a shared capability instead of building their own access management. Teams choosing your design over their own budget is the strongest signal I know of.
• Auditing access went from many steps to one. Answering “what can this person reach?” used to mean opening every user in turn. Now it is a single view.
• Self-service replaced manual intervention for identity-provider and role management, and the support load behind it went with it.

Broad internal adoption across twenty-plus teams is real, but it was partly mandated, so I treat it as context rather than proof. It was also the actual design challenge. When teams have to use your platform, you have to earn the partnership anyway. The category framework was built with those teams, not handed to them.

METRIC Slot any firmer before and after numbers here, such as support-ticket reduction, setup time, or the number of products and roles onboarded.

What I would do differently, and am

The lesson came from living with what shipped.

I had reorganized access around resources, but I still left administrators operating the system to use it. To see anything, you picked a resource type, then its parent, then the specific resource. The data only made sense if you understood it was filter-dependent. Then you cleared it all and reapplied it to look at anything else.

I had removed an identity-centric burden and quietly replaced it with a filter-management one.

The real goal is to never make people manage a view at all. Show them their actual resources, and let access follow whatever they select. That is shaping how I am approaching access management in the platform’s next generation. Same north star as the original reframe, one level deeper.