Two tenants of the same headcount can have wildly different RBAC complexity - one runs on the 5 built-in roles and never thinks about it again, the other needs 30+ custom roles to model a matrixed org. This guide is the design framework we recommend when the role count starts climbing.
The common mistake: 1:1 IdP group mapping
Companies with mature IdP setups often have 100+ AD groups. The instinct is to mirror them all as Apragya roles. Don't. Most of those groups exist for non-Apragya reasons (file shares, ticketing tools, conference room booking). One AD group should rarely become one Apragya role - it's the wrong unit of analysis.
Better: design functional roles, gate within
Apragya AI's RBAC has two layers - the role determines which APPS the user can access; the per-app permission matrix determines what they can DO inside each app. Design ~10-15 functional roles (sales rep, sales manager, AP clerk, AP manager, HR ops, IT admin, etc.) and let the per-app matrices handle finer-grained access.
View scopes - the third dimension
- Mine: the user sees only records where they're the owner/creator/assignee
- Team: the user sees records owned by anyone in their team (HR teams, sales territories, etc.)
- All: the user sees everything in the tenant for that app
Most over-customization on RBAC comes from skipping the view-scope dimension. "Sales reps shouldn't see other reps' deals" - that's a view-scope problem, not a role problem. Set the role to sales_rep, the view scope to Mine, done. Don't make 50 territory-specific roles.
When custom roles are worth it
- Regulatory: financial-services compliance roles often need to be uniquely identifiable in audit logs
- External users: client-portal roles benefit from being distinct from internal staff (cleaner audit, easier UI gates)
- Matrix orgs: a dotted-line reporting structure where someone needs Sales view-scope on territory A and HR Team view-scope on department B - hard to express with the 5 built-ins
A 500-person example
- 1x SaaS Admin (the SaaS provider's contact, not your CIO)
- 1x Platform Developer (the in-house platform engineer)
- 3x Org Admins (IT lead + Finance lead + HR lead - rotating coverage)
- ~12 custom roles for the functional teams (Sales rep, Sales mgr, AP clerk, AP mgr, HR ops, HR mgr, Field service tech, Customer Success rep, Marketing user, BI analyst, Internal auditor, Procurement officer)
- Member role for the long tail of ~470 individual contributors who have lighter, mostly read-only access
- Total: 17 distinct roles, with view scopes doing the heavy lifting of per-record visibility