Permissions · Enterprises Think in Roles, Not People (2022 - 2023)

Everyone read the complaints as a plea for cleaner permission screens. I saw that the screens were never the real problem, the model living underneath them was, so I let e-commerce access control grow up into the kind of IAM that enterprises already trust, and testing scores climbed from 70% to 90%.

The complaints landed on my roadmap looking like a punch list. One person could not install an app because they were not the store owner, someone else had spent an afternoon setting the same six permissions on twelve different users by hand, a third could not tell what a toggle would actually turn off. Every one of them read like a small, fixable annoyance, and every product instinct in me wanted to go clean up the screens.

But I kept staring at that list, and the longer I looked the less it looked like a dozen bugs and the more it looked like one. These were not people fighting with buttons. These were enterprises trying to run an org chart through a tool that had only ever been taught to think about individual people, one at a time. The screens were fine. The idea underneath them was the thing that had never grown up.

What the complaints were really saying

BigCommerce's original permissions model was built for a small team, and for a small team it was honestly dandy. There was one store owner who could do everything, a set of broad permissions you switched on or off, and that was about it. When your whole company is three people in a room, that model is not just enough, it is the right amount of nothing to get in your way.

The trouble starts the moment the company grows. Watch what the old model quietly asked of a larger merchant:

• One person, and exactly one, could install apps and run the key admin tasks, so the whole store waited on a single human being.
• Permissions were vague and carried hidden dependencies, so granting one thing could quietly grant three others, and nobody felt safe.
• There was no such thing as a role, so an admin onboarding ten people set ten people up by hand, one permission at a time.
• Nothing spoke to the enterprise identity systems, like Active Directory, that these companies already ran everything else through.

This is the video we used to show the old flow, editing users one by one. It is fit for an SMB and quietly brutal for anyone bigger.

So, what were merchants actually asking for? Not prettier screens. They were asking to stop managing people and start managing roles, which is a completely different question, and it was one our product could not yet hear.

How I checked I wasn't just guessing

This is the point in a story where it is very easy to fall in love with your own theory and go build it. I have done that before and paid for it, so this time we went and checked. The redesign really took shape at our 2022 permissions offsite, where we wrote our assumptions down in plain sight:

1. Our model made permissions genuinely hard to manage at scale.
2. Enterprises wanted role-based, compliance-friendly control.
3. Large orgs would want to sync everything from a single source of truth.

Then we did the unglamorous work to find out how wrong we were. We sat with seven merchants and an agency, three of them small shops under $5M in GMV and four of them mid-market and enterprise over $20M, with user counts running from under ten people to well past a hundred. We asked them why they touch permissions at all, where it hurts, and how they would run the whole thing in a perfect world, then put a prototype of the new model in front of them to see if it matched the way they actually think.

The readout that came back ran long, so here is the honest short version of what those conversations taught us:

• The single store owner was the biggest pain point, full stop, and role-based permissions were the clear ask, loudest from the larger merchants who called what we had today rudimentary at best.
• Big companies run permissions through a real process. An IT team updates access across every system they own, BigCommerce included, adjusting it a few times a week, while small shops set it once and barely touch it after, closer to monthly or quarterly.
• How much they wanted to lean on external identity, like Active Directory, varied a lot. Some treat BigCommerce as its own island, others want it to mirror the source of truth they already run, and we had to serve both, with SSO as the bridge that was still too thin today.
• The API was a nice-to-have, not a must-have, for almost everyone. Most merchants were happy editing in the UI, which quietly told us the UI itself had to scale past a hundred users, not just the API.
• Permissions were too coarse. Merchants wanted to say who can open Page Builder without letting them touch theme styles, or who can manage orders without being able to override pricing, so they could actually run least-privilege instead of all or nothing.
• Permissions were unclear, and the hidden dependencies were the worst of it. Granting one thing silently granted another, and one merchant had gone so far as to print our whole support page and map every permission to a role in a spreadsheet by hand.

What the research talked me out of

Two things surprised me, and those are always the findings I trust the most. The first is that enterprises did not actually want to hand their entire permission model over to SSO and walk away. I had assumed full automation was the dream. It was not. Plenty of them wanted a human in the loop for the parts that mattered, and forcing them into total automation would have been solving a problem they simply did not have.

The second is that when it comes to permissions, detailed control over who can see and touch what turns out to matter more than the polish of the interface you use to set it. That reordered my whole priority list, and it is exactly the kind of thing you only learn by asking.

What we actually built

With that, the shape of the fix was clear, and it was not a fresh coat of paint. We borrowed the spine from the access management systems the enterprise world had already spent decades getting right, things like Active Directory, and we brought that discipline into e-commerce without dragging its complexity along with it. Concretely, we shipped:

• Groups and roles. You define a set of permissions once, and users inherit them, so onboarding ten people becomes one decision instead of ten.
• Multiple store owners. Full admin rights stop living inside a single human being.
• Cross-store management. A role can reach across many stores, which is exactly how a real merchant with a real portfolio actually operates.
• One-step group creation. Making and editing a group is a single, legible flow, not a scavenger hunt.
• A UI for the small teams and an API for the big ones, so the same model serves the shop of three and the enterprise of three hundred without either one feeling like it is using somebody else's tool.

We prototyped the group creation, editing, and bulk-user flows, then sat with IAM, engineering, product, and actual merchants to sand the thing down. Here are the happy paths for the most common flows.

I did not do any of this alone. This lived inside our Identity and Account Management team, and I had the good luck to build it with people who knew their corner far better than I did. Kate Wagner ran research with me, from the interviews through the readout that kept us honest about what merchants actually wanted, and Piotr Kaminski drove the thornier framework question of how the domain teams across BigCommerce would define and expand their own granular permissions, which was a cross-functional effort well past any one team. My own job was to lead the work from the first research through the high-fidelity prototypes, hold the IAM discipline without losing the SMB ease, run the workshops with IAM, product, and engineering, and turn everything we heard into the handful of design choices that would actually move the thing.

What it added up to

So did it work? The redesign tested at 90% usability, up from 70%, which is a big jump for something as unglamorous as permissions. But the number I actually cared about was what came out of merchants' mouths.

"I could switch tomorrow and be happy."

"This is exactly what we want and need."

• One clear place to see every permission, written in plain language instead of riddles.
• Multiple store owners and role-based groups, so the org chart finally fit the tool.
• A security and transparency story that holds up for a global enterprise and still does not get in a solo owner's way.
• A model that lines BigCommerce up with the access management the rest of the SaaS world already expects.

The lesson I carry out of this one has almost nothing to do with permissions. When customers hand you a list of complaints, they are describing symptoms, every single time, and the list will always beg you to go fix each symptom one by one. The actual job is to sit with the whole list until the one disease underneath it shows itself, because you can polish a screen forever and never touch the thing that was wrong. This was never a UI upgrade. It was teaching a product built for one person in a room to think the way a whole company already does, and that, in my experience, is the difference between shipping a feature and moving a platform.