Roles & permissions at a glance
Purpose
There is one permission model, and it applies identically everywhere: in the interface, over the API, in automations and for the AI. Understanding the permissions once means understanding them for the whole system.
That is more than convenience. A second permission model for a second access route is the most reliable way to build a data leak: it is maintained correctly once and forgotten thereafter.
Scope
- Permissions in the pattern
module.object.action— readable from the name alone: who may do
what to which thing.
- Roles bundle permissions. Accounts receive a role, not individual permissions.
- Permissions add up; there is no forbidding. Someone who sees too much was granted it somewhere
— not deprived of it somewhere else. That makes fault-finding unambiguous.
- Object-level checking. Not merely "may this person read customers" but "may they read this
customer". Access through guessed identifiers is thereby ruled out.
- Brand scope follows the permission. Where data belongs to a brand, a permission applies in
exactly the brands it was assigned in — not in every brand where somebody has some membership.
- A separate portal realm. Customer access lives in its own sign-in area with its own
object-bound releases, see Customer portal.
Interplay
New plugins bring their own permissions, granted to nobody to begin with — a module never widens authority automatically. Every permission change and every action taken under a permission appears in traceability.
Limits
- Only allowing, never forbidding. Exceptions of the kind "everything except this one customer"
cannot be expressed as a permission.
- Whoever may manage roles can grant themselves anything. That single permission is effectively
the highest in the system and should be handed out correspondingly rarely.
- Permissions are loaded at sign-in. A change takes effect for a signed-in person only after
signing in again.