Enterprise-ready playbook
Ship organizations and delegated admin
Updated 2026-07-19
Why enterprises demand it
- Enterprises expect to self-administer their own users and settings
- Every other enterprise feature (SSO, SCIM, audit, roles) attaches to the Organization
- Delegated admin removes you from the loop for routine user management
How to implement
- 1Make the Organization the configuration boundary for SSO, SCIM, roles, and audit
- 2Support users belonging to more than one organization
- 3Provide delegated admin so customers manage their own users and roles
- 4Add organization switching for multi-org users
Standards
- Multi-tenant data isolation
- OIDC (org context in tokens)
Pitfalls
Retrofitting tenancy later
Adding organizations after launch means rewriting authz and data access.
No delegated admin
If every user change routes through you, you become the bottleneck.
Weak tenant isolation
Cross-tenant leakage is the worst B2B failure; isolate rigorously.
Build checklist
- Organization as the configuration boundary
- Users can belong to multiple organizations
- Delegated admin for customer self-service
- Rigorous tenant isolation, tested
What to require of a platform
- Native organizations / tenants
- Delegated administration
- Strong tenant isolation
Build it: blueprints
FAQ
- Why model organizations before other enterprise features?
- Because SSO, SCIM, roles, and audit all attach to the Organization. If you add tenancy later, you end up rewriting authorization and data access. Model the Organization as the configuration boundary first.
- What is delegated admin and why does it matter?
- Delegated admin lets customers manage their own users, roles, and settings without going through you. It removes you as the bottleneck for routine changes, which enterprises expect.