Role-based access control (RBAC)

RBAC puts a layer between people and permissions: users get roles, roles hold permissions, and code checks permissions. The discipline that makes it worth the indirection is checking can(user, 'invoice:delete') and never if (user.role === 'admin'), because the second form means a new 'billing manager' role turns into a hundred edited conditionals. In a multi-tenant product the role belongs on the membership row, not the user row: the same person can own one workspace and be a viewer in another, and their permissions have to change when they switch context.

Start small, because you can always add. Owner, admin, member, viewer covers most B2B products, plus one billing permission that owners keep to themselves. Write the permission matrix as a literal table (roles down the side, permissions across the top) and generate the check function from it, so the docs and the enforcement cannot drift apart. Protect the last-owner case: never let someone remove or downgrade the final owner of an organization.

Gotchas: role explosion, where every 'they should be able to X but not Y' request adds a role until you are maintaining forty of them. When the rules start depending on the resource rather than the person (only records they created, deals above a threshold, during business hours), roles have run out and you want ABAC or ReBAC instead. And hiding the delete button is presentation, not access control: the same check has to run on the server, since the client is just a suggestion.