Overview of Security Groups
A security group is a named set of users. Permissions are granted to groups; people get access by being in one.
Where to find it
Architect Panel → Security:
- Permissions — the named permissions granted to groups
Architect Panel → Data:
- Datastores — the Permissions row action, where a group is granted access
Groups themselves are created in the Admin Panel sidebar, under User Administration → User Groups — not in the Architect Panel. The Architect Panel is where you grant a group access to things.
Why groups rather than people
Because permissions granted to individuals cannot be reviewed. Ten people each granted access to eleven things is a hundred and ten decisions nobody can hold in their head, and every joiner repeats the work while every leaver leaves some of it behind.
Granting to a group turns that into one decision per group, and joining somebody becomes a single action with a predictable result.
What a group carries
A name, and an admin access level. The permissions it holds are granted separately, per datastore and per field.
Design around roles, not people
Name groups after what people do — Caseworker, Finance, Service Desk — not after individuals, teams that get renamed, or projects that end. A group called after a role survives reorganisation; one called after a department does not.
Keep the set small
Most organisations need fewer groups than they create. The instinct to make a group per team produces a set nobody can reason about, with heavy overlap and no clear answer to what any individual can actually reach.
Start with the smallest set that expresses genuinely different access, and add one only when you can say what it permits that no existing group does.
Overlap is normal
People belong to several groups and accumulate the union of what those groups grant. That is the intended design — a caseworker who also does finance is in both groups rather than needing a third.
It is also why adding somebody to a group to solve one problem can grant more than intended. Check what a group actually holds before adding people to it.
Review membership, not just permissions
Most access reviews look at what groups can do and stop. The more common problem is who is in them — people accumulate memberships as they move roles, and nothing removes the old ones.
Worked example
An organisation with 200 staff runs seven groups: Service Desk, Caseworker, Senior Caseworker, Finance, Reporting, System Administrator and a small Auditor group with read-only access. A new starter is placed in one or two, and their access is correct immediately with no individual decisions.
Recommendations
- Never grant permissions to an individual.
- Name groups after roles, not teams or people.
- Justify each new group against the existing set.
- Review membership annually, not just permissions.