RBAC
Role-based access control assigns permissions to roles, then assigns users to those roles.
Compare access models →Access model basics
Short definitions for the terms teams use when they design role-based access control.
Role-based access control assigns permissions to roles, then assigns users to those roles.
Compare access models →A role is a named collection of permissions that represents a job or responsibility.
See role design patterns →A permission states whether a role may perform an action on a resource, often under a condition.
Design permissions step by step →A resource is the thing an access model protects, such as a deal, report, user, or account.
Define resources and actions →An action is an operation a user may take on a resource, such as view, create, edit, or delete.
Define resources and actions →Role inheritance lets a child role receive a parent role's permissions and override only the differences.
Model role inheritance →A field-level permission controls access to specific fields rather than exposing every field on a resource.
Read the field-level guide →Least privilege gives each role only the access it needs to do its job.
Design for least privilege →A permission matrix maps roles to resources and actions so a team can review who can do what.
Use the permission matrix template →Scope limits a permission by context, such as a user's own record, same group, or another group.
See scopes in multi-tenant SaaS →Delegation lets one role act on behalf of another role or within a defined responsibility boundary.
Model admin responsibilities →Relationship or user context describes how the actor relates to the record, such as owner, peer, or superior.
Go beyond role and action →Relationship-based access control uses relationships between users, resources, and groups to determine access.
Compare access models →Attribute-based access control makes decisions from attributes of the user, resource, action, or environment.
Compare access models →