How it works
How access works
Why ROK grants access through groups rather than job titles, what the role field actually does, and where the real boundary sits.
Most systems ask "what is this person?" and hand out access by title. ROK asks "what should this person be able to do?" and hands out permissions, bundled into groups.
Groups, not titles
A permission is a single capability — Publish, Manage groups, Award badges. A group is a named bundle of them. A person belongs to any number of groups, and what they can do is the union of every group they're in.
That means:
- Giving someone one extra capability doesn't require inventing a new job title.
- Removing someone from a group removes exactly what that group granted, and nothing else.
- Two people with the same title can legitimately differ, which is how real agencies work.
Your groups are listed under People & access → Groups (opens the admin console), and the full catalog of permissions — in plain language — is at Permissions (opens the admin console).
The role field grants nothing
Each person also has a role value that reads operator, author or similar. Nothing
consults it. It is a display hint so lists have something human to show.
If you want to know what someone can actually do right now, open their profile from Users (opens the admin console). The effective permissions panel lists the resolved union, and names which group granted each one.
It is per tenant
Group membership belongs to a tenant, not to a person globally. Someone who works with two agencies has one login and one profile, but separate memberships — an author in one, an operator in the other. Switching the active agency switches which set applies.
Hiding a button is not security
The console hides controls you can't use, so the screen stays honest. That is presentation.
The actual check runs in the database on every read and write. If someone reached a hidden control — by URL, by an old bookmark, by anything — the database still refuses. This is worth knowing for a practical reason as well as a reassuring one: when an action is refused despite the button being visible, the answer is a missing permission or an unmet condition, not a broken screen.
Two things groups don't govern
- Getting into the agency at all. Operators join by redeeming an access code; staff are invited by someone with Manage users. See Access codes (opens the admin console).
- Being suspended. Suspension is separate from group membership. A suspended person keeps their groups and still can't get in — which is what you want when the situation is temporary.
See also
- How it worksAgencies, members and what's separateHow ROK keeps each agency's content, people and recognition apart — and what changes when someone belongs to more than one.
- How it worksHow publishing worksThe path a piece of content takes from a blank draft to something an operator can read offline — and what the database will and won't let you skip.
- ReferencePermissionsEvery permission in ROK in plain language — what each one lets someone do, where it shows up in the console, and which built-in groups carry it.