Security Groups

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.

Creating a Group

Groups are created in the Admin Panel; what they may reach is granted in the Architect Panel. Knowing that split saves a lot of looking.

Where to find it

Architect Panel → Data:

• Datastores — the Permissions row action — where the group is granted access

Architect Panel → Security:

• Permissions — named permissions
• Record Access Roles — row-level grants

To create one: Admin Panel sidebar → User Administration → User Groups → new record.

Admin access

A group carries an admin access level, and it is the field to think hardest about. It governs administrative capability rather than access to any particular datastore, so it is not narrowed by the permissions you grant afterwards.

Leave it at the lowest level unless the group genuinely administers the platform. A group with administrative access and carefully limited datastore permissions is not carefully limited.

Bringing a group into use

1. Create it with a clear, role-based name.
2. Grant its datastore permissions via the Permissions row action on Data → Datastores.
3. Set field-level access where the datastore uses field security.
4. Add one test user.
5. Sign in as them and confirm what they can and cannot reach.
6. Only then add everybody else.

Test with one person first

This is the step people skip, and it is the one that prevents the common failure: a group granted less than intended, added to forty people, each of whom raises a ticket the following morning.

Verifying as a real member takes five minutes. As an administrator it proves nothing, because administrators generally see everything.

Grant nothing by default

Start a new group with no permissions and add what it needs. Copying an existing group is quicker and carries across everything that group had accumulated, including whatever it should not have had.

Write down what it is for

One line, somewhere durable: what role this group represents and why it exists. Groups outlive the people who create them, and the commonest reason nobody removes a redundant group is that nobody is certain what it does.

Do not create a group per person

A group with one member is an individual grant with extra steps. If somebody genuinely needs unique access, that is usually a sign the role definitions need revisiting rather than a new group.

Worked example

A team creates a Reporting group with read-only access to four datastores and no administrative level. One analyst is added and signs in to confirm they can read what they need and cannot edit anything. The remaining six analysts are added the same afternoon, and no tickets follow.

Recommendations

• Keep admin access at the minimum.
• Start from nothing, rather than copying a group.
• Test with one member before adding the rest.
• Record what the group is for.

Managing Membership

Membership is what turns a group's permissions into somebody's access.

Where to find it

Architect Panel → Security:

• Disabled User Accounts — accounts closed administratively
• Record Access Roles — per-record grants, which are separate

To manage it: Admin Panel sidebar → User Administration → All Users, find the person, and use the Manage Security Groups row action.

It is a row action, not a menu

This catches people out. There is no separate membership screen — you find the user and act on their row. A good deal of the platform works this way, and it is worth checking for a row action before concluding something is missing.

Membership is per identity, not per person

Groups attach to the three-part identity — sign-in method, identifier and domain. Somebody who exists both as a local account and as a single sign-on identity has two identities, and adding one to a group does not add the other.

This is the usual explanation when a user says their access changed after signing in "the other way".

Joiners

Add people to groups as part of onboarding, not when they first hit a wall. Access arranged reactively is access nobody reviewed, and it tends to be granted generously because somebody is waiting.

Movers are the hard case

Leavers are usually handled. Movers are not: somebody changing role is added to their new groups and left in the old ones, because removing access nobody has complained about is not on anybody's list.

Over a few years that produces staff with access spanning every role they have ever held — the commonest finding in any access review, and entirely preventable by making removal part of the same task as addition.

Leavers

Where accounts come from a directory with provisioning, deactivation is usually handled for you. Local accounts are not — check them explicitly, and remember they are disproportionately privileged.

Delegated management

Group management can be delegated, so a manager may assign only the groups they are responsible for. That is a good way to keep membership current without giving out broad administrative access.

Where you delegate, be clear what each delegate may grant, and review those arrangements as you would any other permission.

Removing membership does not remove record grants

A person removed from a group loses what that group granted, but any per-record access granted to them individually remains. Check record grants when somebody changes role, particularly ones with no expiry.

Worked example

An organisation adds group changes to its movers checklist: on every internal move, the manager confirms which groups to add and which to remove. An access review a year later finds nobody holding access from a previous role — the first time that had been true.

Recommendations

• Handle movers, not just joiners and leavers.
• Check the identity route when access seems inconsistent.
• Delegate membership rather than handing out admin access.
• Review individual record grants when somebody changes role.

Built-in Groups

Five groups exist from the start. Two of them behave differently from the rest, and knowing which saves confusion.

Where to find it

Architect Panel → Security:

• Permissions — what these groups are granted
• Record Access Roles — row-level access, granted separately

The five

• Super Administrator — full administrative access.
• All Anonymous Visitors — everybody who is not signed in.
• All Users — everybody who is signed in.
• Restricted Accounts — for accounts that should be held back.
• Store Owners — a commerce administrative group.

Two are automatic, not assignable

All Anonymous Visitors and All Users are memberships the platform decides. You do not add anybody to them, and they do not appear as options when managing somebody's groups.

They exist so you can grant something to everybody signed in, or to the public, without maintaining a list. That makes them powerful in one direction: anything granted to All Users is granted to every account you have, including ones created tomorrow.

Treat All Users carefully

It is the right place for genuinely universal access — a staff directory, a policy library. It is the wrong place for anything you would want to review, because there is no membership to review.

Check what it holds periodically. A permission added to All Users for a good reason three years ago is a permission everybody now has, and nothing about it will look unusual.

All Anonymous Visitors is a public grant

Anything granted to it is available without signing in. That is occasionally exactly right — a public register, a form the world may submit — and it deserves deliberate review, because it is the one group whose grants are visible to anybody at all.

Super Administrator

Full administrative capability, and effectively exempt from the restrictions you configure elsewhere. That has two consequences worth stating:

• Membership should be short and reviewed. Two or three people, not a dozen.
• You cannot verify any permission configuration while signed in as one, because you will see everything regardless.

Do not repurpose the built-ins

They are shipped with meanings the platform relies on. Renaming one to suit a local convention, or using Restricted Accounts for something other than restricting, produces a system whose behaviour does not match its labels — and the next administrator will believe the labels.

Worked example

A review of what All Users can reach finds read access to a datastore added during a project two years earlier, which now holds supplier contact details. It was invisible in every access review because the group has no membership list. The permission is moved to a specific group, and All Users is added to the annual review checklist.

Recommendations

• Audit what All Users can reach annually — nothing else will surface it.
• Review anonymous grants deliberately; they are public.
• Keep Super Administrator to two or three people.
• Never verify permissions as an administrator.