Start with the job
Define what a person needs to accomplish before naming a role. The job gives you a smaller, clearer starting point than copying every permission available in the system.
Guide
Least Privilege RBAC Design: Start with the Smallest Safe Model
Least privilege is a design decision made before implementation. Define the smallest useful access model for each job, then make scope and exceptions visible instead of giving everyone an admin role.
Design least privilege before you code
Set the resource boundary
Decide which organization, team, project, or record group the role can reach. Scope keeps a useful role from becoming a blanket grant across the whole product.
Add only required actions
Separate view, create, edit, approve, and delete decisions. If a workflow does not require an action, leave it out instead of granting a broad admin shortcut.
Handle exceptions explicitly
Use inheritance, relationships, and field-level conditions for the exceptions that matter. Do not create a new role for every combination of team, tenant, or record state.
Why “admin for everyone” is not a design
An admin role can be useful for a small, trusted set of operators, but it should not stand in for requirements. When everyone is an admin, the team cannot see which access is necessary, which boundary is intentional, or where a workflow needs a narrower role.
Admin for everyone
Giving every teammate an admin role is easy to explain at first, but it hides the actual access model. People receive permissions for workflows they do not own, review, or need.
Role names as requirements
Names like “manager” or “operator” do not say which resources or actions are allowed. Translate the job into concrete scope and action decisions before building the role.
One-off exception roles
A new role for every special case makes least privilege harder to review. Keep the base role stable and model the relationship or field condition that narrows the exception.
Review the model as a team
A least-privilege model should be explainable in a review: who gets access, to which resources, for which actions, and under which conditions. A visual model makes those boundaries easier to challenge before they become code.