Skip to main content
Use this when your customers are external companies, each represented by an Auth0 Organization, and access in your product follows who’s a member of which organization, with, optionally, different roles within it (admin vs. viewer, for example).

​
Model

If organization membership is all you need, every member gets the same access with no finer distinction. You only need: If different members need different access, add roles. Which shape those roles take depends on where they come from:
  • Static roles, defined once by your application as a fixed set of named permissions (like an “Approver” role): model each as its own named relation directly on organization, per Roles: Static roles.
  • Dynamic roles, defined by each customer or organization themselves, with names, IDs, and permissions your application can’t know ahead of time: model these generically, wired through an intermediate organization_membership object so a role assignment can be revoked without knowing which roles a user held, as covered in Roles: a user, within an organization membership.
Some applications need only one category; others need both, in which case add both sets of relations to the model above, following Roles: Combining both.

​
Mapping

Every setup needs these two rules for organization membership itself:
If you need roles, add the role-assignment rules from whichever Roles subsection matches your case on top of these.

​
Known limitations

Roles have no CRUD events at all, and there’s no event for assigning a tenant role outside an organization context; see Known limitations for the full list that applies to this use-case.