In Episode 1 of What the SaaS?!, we named the identity wall. In Episode 2, we laid the architectural foundation. In Episode 3, we talked about collapsing time to trust with the OIN and Express Configuration.

Episode 4 asks what happens after all of that works. Your enterprise customers are live. Now what?

Now they need to run their own world inside your product. And if you have not solved delegated administration, you have not actually solved enterprise readiness. You have just moved the problem one step down the road.

I brought in Brittany Roth, Senior Product Manager at Auth0, who leads our delegated administration product. What she helped me see is that delegated administration is not a UX problem or an operations problem. It is a trust problem. And getting it wrong does not just create friction. It actively erodes the relationships you worked so hard to build.

The Operational Reality Nobody Talks About

We started the conversation with a scenario: a B2B SaaS company that just landed its 100th enterprise customer. On paper, that is a great day. In practice, if they have not solved delegated admin, it is the beginning of a slow grind.

Brittany was direct about what that grind looks like:

"Every routine change — adding a user, updating an SSO connection, rotating a domain or a certificate — turns into a support ticket. And the IT admin filing those tickets is not a novice. These are people who run their company's identity stack and network. They are completely capable of managing their own environment. They are just not allowed to."

That image stuck with me. A sharp IT admin, filing a ticket to add one person to one system. A special kind of frustrating. And every enterprise customer you sign multiplies it.

The inverse is equally bad: some companies skip the ticket queue entirely and just hand the customer a super admin login and hope for the best. Both extremes fail. The answer is what Brittany calls scoped self-service.

What is Scoped Self-Service?

Scoped self-service sounds simple. Give customers admin access to exactly what they need, nothing more. In practice, drawing that line correctly is one of the harder design problems in this space.

Brittany walked through what it looks like when it works: customers can invite members, assign roles, offboard departing employees, configure SSO, and manage their domains — all without opening a ticket. But they cannot see other customers' data, touch tenant-level configuration, and accidentally do something that ripples beyond their org.

"Access without boundaries is chaos, not control. Real control means your admin knows exactly what's going to happen when they change a setting, who it'll affect, and when it takes effect."

The security underpinning access is not optional. Brittany outlined four principles she always comes back to:

1. Platform-layer isolation (the boundary lives in the API, not the application code).
2. Trust nothing and validate everything (org IDs live in the signed token, not the URL).
3. Least privilege applied deliberately.

Tenant-level guardrails that let the SaaS vendor set the ceiling on what customer admins can configure.Without those four, you cannot safely give customers self-serve power. You can only give them the illusion of it.

The most interesting part of our conversation was about design philosophy, specifically about fear.

Enterprise IT admins manage critical infrastructure. They have all either locked someone out of their own system, or watched a colleague do it. That experience does not make them gun-shy. It makes them deliberate. And your tool either helps them move with confidence, or it forces them to tiptoe.

Brittany's framing: the fear in any high-stakes interface comes from irreversibility.

"The admin's brain is asking one question before they hit save: if I do this wrong, can I undo it? If the answer is yes, they're willing to try. If the answer is no, they freeze."

So you build the safety nets that answer the question before they have to ask it:

• Let them test an SSO configuration against a real login attempt before it goes live.
• Show them exactly what is about to change before they apply it.
• Scope mistakes to a single org so one admin's error never affects anyone else.
• Design for the worst case: when all the prevention fails and someone does lock their entire company out, there has to be a path back in that does not require calling your support team.

"If your admin can't self-serve their way out of an oops, you haven't actually solved the original problem. You've just relocated it."

The Admin Is Your Customer Too

The mindset shift Brittany closes with is the one I keep coming back to: treat the IT admin as a first-class user. Not as internal tooling. Not a secondary persona. Not the dashboard you rush through at the end of a sprint to satisfy a sales checklist.

"A product that only delights end users is easy to replace. A product that delights end users and gives admins what they need to trust it—clarity, control, predictability—stays embedded for a decade. That's the difference between a tool and a partner."

What I did not fully appreciate before this conversation is how much the admin experience shows up before the deal closes. When your platform supports custom Role-Based Access Control (RBAC), granular audit logs, System for Cross-domain Identity Management (SCIM), and fine-grained permissions, the security review goes from a multi-month interrogation to a brief formality. The conversation shifts from "Can your product do X?" to "How would we configure it for X?" That shift, Brittany said, is the real maturity signal.

And post-deal close: an IT admin who has wired your product into their identity stack, audit pipeline, and automation is not going anywhere. They are not even looking. Their growth becomes your growth.

Where to Start If You Cannot Build Everything at Once

For SaaS teams with limited engineering bandwidth — which is most of them — Brittany has a clear answer: identity provider management first. Not just SSO, but domains, SCIM provisioning, and attribute mappings. The whole enterprise Identity Provider (IdP) setup.

Identity provider management is simultaneously the highest-volume support driver, the capability enterprise customers most want to control themselves, and the single clearest signal of enterprise readiness. Without it, the security and IT teams at any company over 100 people will block you before you even get in the door.

The good news: you do not have to build it from scratch. Auth0's My Organization API and embeddable UI components give you that pre-built, brandable interface out of the box. Days of integration work, not months.

Build a Different Kind of Relationship with Your Enterprise Customers

Delegation, done right, is a form of respect. It says: we trust you to run your own environment. We have built the guardrails to make that safe. We have designed this so that when you make a mistake — and you will, because everyone does — you can recover without calling us.

The SaaS companies that get this right do not just reduce their support costs. They build a different kind of relationship with their customers. One where the IT admin is an advocate, not a friction point. Where growth is self-reinforcing rather than sales-dependent. Where the product works so well that customers don't think about it — it just works.

If your enterprise customers are still filing tickets to make basic admin changes, that is not a support problem. It is a product problem. And it is a very solvable one. Consult our team to learn more about bringing true delegated administration to your platform.

To hear the full deep dive into this, listen to the complete episode of What the SaaS?!.