Capability
Permission you can reason about, and a boundary nobody can talk their way past.
Capabilities are grouped into entitleable modules. Roles describe what a job can do, groups describe who does that job, and a person's effective capability is the union of their groups intersected with the modules your plan includes — recomputed on every check, never flattened and cached.
Eight things that hold, whatever anybody configures.
You cannot grant what you do not hold
Otherwise any role editor becomes a privilege escalation path straight to full administration.
Managing permissions is itself a permission
Role management is a capability like any other, and it can be given to some people and not others.
A tenant can never self-entitle
The commercial boundary is enforced server-side, not by hiding a button in the tenant admin interface.
You cannot lock yourself out
Removing the last holder of role management is refused with an explanation, because the alternative is a support call and a bad day.
System roles cannot be edited or deleted
They are the migration target for existing users, and breaking them breaks access silently.
Unknown capabilities are refused on save
A typo that silently grants nothing is a support ticket. One that silently grants something is a breach.
Revocation takes effect immediately
Effective capability is cached briefly and invalidated on every role, group, membership and entitlement change. A stale cache is a permission that outlived its revocation.
Empty means none
An empty capability set is no access, never unrestricted. The whole model fails closed.
The controls a policy document only asks people to observe.
Every built-in role has an exclusion list, and the exclusions are the point. Somebody who can edit a record and also decide what a subject access request discloses about it could tidy the record first. Somebody approving their own campaign is not review. So neither is possible.
Scoping works alongside this. Campaigns and the asset library can be scoped to top-level categories per group, so a regional team sees its own campaigns without a separate tenancy. Scope narrows and never grants, an empty scope means everything, and where somebody belongs to several groups the scopes union rather than intersect — which is the behaviour people expect and the opposite of what a naive implementation does.
- The Data Protection Officer role holds no write access at all
- An asset editor cannot publish or delete
- The proposer of a purchase-order amendment can never approve their own
- Every destructive action asks for confirmation in one consistent, brandable dialogue
Two questions, two code paths.
They look similar and must never share an implementation.
Questions about access control
Why groups as well as roles?
Because direct user-to-role assignment does not survive an organisation of any size. 'Everyone in the Cardiff contact centre' is a group, and its permissions change once rather than person by person. Roles describe what a job can do; groups describe who does that job. A person can be in several groups and their capabilities are the union.
Can I build my own roles?
Yes, from the capability list within the modules you are entitled to. The built-in system roles cannot be edited or deleted, because they are what existing users are mapped onto, but you can create as many of your own as you need.
Does the API enforce the same rules as the screen?
Yes, and this is checked rather than asserted. Guessing an administrator-only URL is refused by the server independently of what buttons happen to render, and API responses are redacted to exactly what a tenant administrator would see on screen for that person. Validation lives in the service, so the API and the interface cannot disagree about what is legal.
Can a tenant admin create another administrator?
No. A tenant administrator can add staff at the two staff tiers, but promoting somebody to administrator is a platform-operator action for your tenancy. It prevents a tenancy minting its own peer administrators, which is a boundary worth keeping even though it occasionally costs a phone call.
What about a reseller acting for several tenants?
That is the delegation model. A delegated API key names the tenants it may act for and must state which tenant each call is for and who is acting — neither is ever inferred. A key naming no tenant is refused. A key naming a tenant outside its scope is refused and audited. Only a platform administrator can mint one.
Related capabilities
The fastest way to evaluate a permission model is to try to express your own awkward reporting line in it. We are happy to do exactly that.