Documentation / Platform glossary / Role-Based Access Control
Role-based access control grants permissions to roles rather than to individuals, and assigns people to roles. Access follows from what someone does, so a change of responsibility is a change of role assignment — not an audit of every individual permission that person accumulated.
RBAC has three elements: users, roles, and permissions. Permissions are attached to roles; users receive roles. Nothing is granted to a user directly, which is what makes the model reviewable — the question "who can approve a requisition" has an answer that does not require enumerating every account.
Two principles govern good role design. Least privilege means a role carries only the permissions its function requires. Separation of duties means no single role can both initiate and approve a sensitive action, which is a control against error as much as against fraud.
The characteristic failure mode is role explosion. When each exception becomes a new role, the model degrades into per-user permissions with extra indirection, and the reviewability that justified RBAC is lost. The usual remedy is a small set of well-designed roles plus attribute-based conditions for genuinely contextual decisions, rather than an ever-growing role catalogue.
RBAC answers what a role may do. It does not by itself answer which records the role may act on — that is a scoping question, and in multi-tenant systems the tenant boundary must constrain a role's reach regardless of its permissions.
Access review is a recurring compliance obligation, and RBAC is what makes it tractable. Reviewing a dozen role definitions and their membership is achievable; reviewing thousands of individual grants is not.
RBAC also makes joiner-mover-leaver processes reliable. Movement between functions is handled by reassignment, which is far less error-prone than incrementally adding permissions and rarely removing them.
QueryTek applies role-based access within the tenant boundary, so a role's reach is limited to the customer environment it belongs to. Roles are designed for review rather than convenience. Specific role definitions and permission mappings are provided through direct engagement.
