Roles and permissions
Custom roles, why permission is asked of the database, and what a revocation actually guarantees.
Roles are yours
The platform ships default roles, but your organization can author its own, combining whatever permissions fit your structure. A role that only reads privacy, one that administers suppliers without touching billing, one that reviews documents and nothing else.
The question is what you may do, not what you are called
Internally, the platform never decides by comparing a role's name. It asks whether that user holds that permission, and the answer comes from the database.
The difference is not subtle. Comparing names worked while every organization had the same three roles, and stops working the moment a customer authors one. A role holding the permission to administer the organization is an administrator in every sense that matters — and a name comparison would refuse it for not being spelled "admin".
Two layers, not one
The application check and the database isolation policy consult the same source, on purpose: that way a screen and a query cannot disagree about the same user.
They have distinct jobs. The database layer is what guarantees isolation — coarse and inescapable. The application layer is what provides expressiveness, allowing fine permissions per action. The first is the security; the second is the precision.
Effect of a change
Changing someone's role applies on their next action, because permission is consulted at use time rather than stored in the session. There is no need to ask the person to sign out and back in.