Security Groups

The unit permissions are granted to, the five built-in groups and what they mean, and how membership is managed.

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

Create it with a clear, role-based name.
Grant its datastore permissions via the Permissions row action on Data → Datastores.
Set field-level access where the datastore uses field security.
Add one test user.
Sign in as them and confirm what they can and cannot reach.
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. It is changed on one screen, the Security Group Manager, which you open from the person's row in the user lists, whether they sign in with a local account or through single sign-on.

Where to find it

Admin Panel → User Administration:

All Users — local accounts; the Manage Security Groups row action opens the Security Group Manager
External / SSO Users — people who sign in through Active Directory, Azure AD, SAML or a social provider; the Security Groups row action opens the same screen
User Groups — where the groups themselves are created

Architect Panel → Security:

Security Group Managers — who may hand out which groups without being an architect
AD Group Mapping — Active Directory groups that confer a security group at sign-in

It is a row action, not a menu

There is no separate membership screen in the menus. You find the person and act on their row. A good deal of the platform works this way, so check the row actions before concluding something is missing.

Changing someone's groups

Open All Users for a local account, or External / SSO Users for a single sign-on identity, and find the person.
Use Manage Security Groups (or Security Groups on the external list). The Security Group Manager opens, naming the user and how they sign in.
Each group is listed with its description and a User is Member switch. Turn on the groups the person needs and turn off the ones they no longer need.
Click Save Permissions.

An architect sees every group. A delegated manager sees only the groups they have been allowed to hand out, and only for people within their scope: see Delegating Group Management.

Rows you cannot switch

Groups granted by Active Directory. For somebody who signs in with Active Directory, a group they hold because of an AD group mapping is shown switched on and locked, naming the AD group responsible. Switching it off here would change nothing, because the directory grants it again at the next sign-in. Remove the person from that AD group instead. If the directory cannot be reached, a banner says so and those groups are shown as if not held.
System groups. A small number of groups exist for the platform's own use and cannot be given members; the description column explains why.
Your own groups. A delegated manager cannot change their own membership ("You cannot change your own security groups."). Only an architect can.

Membership is per identity, not per person

Groups attach to the three-part identity: sign-in method, identifier and identity source. 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, movers and leavers

Joiners: add people to groups as part of onboarding, not when they first hit a wall. Access arranged reactively is granted generously because somebody is waiting.
Movers: the hard case. People changing role are added to new groups and left in old ones. Make removal part of the same task as addition.
Leavers: directory-backed accounts are usually deprovisioned for you. Check local accounts explicitly, and disable rather than delete.

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

A caseworker who signs in with Active Directory moves to the finance team. An administrator opens External / SSO Users, finds them, and uses Security Groups. Finance is switched on and Caseworker is switched off. The Staff group is shown locked, granted by the "All Staff" AD group, which is correct and stays. Save Permissions is clicked, and reopening the screen confirms the new memberships.

Recommendations

Handle movers, not just joiners and leavers.
Change AD-granted groups in the directory, not on this screen.
Check the identity route when access seems inconsistent.
Delegate membership rather than handing out architect 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.

Delegating Group Management

Delegated group management lets people who are not architects put others into security groups, limited to the groups you choose and, optionally, to the people from one directory or identity provider. Use it so a team leader, a regional IT desk or a customer's own administrator can keep membership current without being given broad administrative access.

Where to find it

Architect Panel → Security:

Security Group Managers — each row grants one editor group the right to hand out one target group
AD Group Mapping — puts directory users into a security group from their Active Directory groups

Admin Panel → User Administration:

User Groups — create the editor and target groups
My Domain's Users — the list a manager uses to find people from their own directory
All Users — local accounts, with the Manage Security Groups row action

How a delegation works

Each row on Security Group Managers is one grant of authority, with four parts:

The editor group: who the managers are. Anybody in this security group holds the grant.
The target group: the one group they may add people to and remove people from.
Limit to Login Method: restricts them to people who sign in with one method, such as Active Directory. Leave it empty for no limit.
Limit to Identity Source: restricts them further to one source within that method: the domain's row ID for Active Directory, the row ID on Azure AD Tenants for Azure AD, the row ID on SAML Identity Providers for SAML, or 0 for local accounts and social logins. Leave it empty for no limit.

A group is offered to a manager for a given person only when a single row both grants that group and covers that person. Empty limits mean "anybody", which is what every delegation created before the limits existed carries.

What a manager can never do

Change their own groups. They see "You cannot change your own security groups." Only an architect can, which stops a delegation turning into a promotion.
Reach a group they have no row for, or a person outside their limits. These checks are made on the server when the screen is drawn and again when it is saved, whatever the list shows.
Act on somebody who does not exist. The person must be a real local account or a known external identity.

Every refusal is written to the Error Log with the manager and the person they tried to change.

Setting up a manager for one directory

Example: anyone in the Contoso IT Support AD group may put Contoso users into Field Engineers, and nobody else's users.

In User Groups, create the target group (Field Engineers, with no admin access) and the editor group (Contoso AD Managers, with admin access level 1). Level 1 is needed because the Security Group Manager is an administrative screen. Never use level 2, which confers architect access.
Put the managers in the editor group. Either map the AD group to it on AD Group Mapping, so membership is held in the directory and picked up at each sign-in, or add people individually with the Security Group Manager.
On Security Group Managers, add a row: editor group Contoso AD Managers, target group Field Engineers, Limit to Login Method Active Directory, Limit to Identity Source the contoso.com domain's row ID. Add one row per group they may hand out.
Give the editor group the My Domain's Users tile in the Admin Panel (item permissions are set from the item's row in Admin Panel Builder; see Admin Panel). That tile lists only people who sign in from the same directory or provider as the person viewing it. Grant this rather than External / SSO Users, which lists everybody.
Give the editor group Read on the datastore behind that list: in Architect Panel → Data → Datastores, find the .users-externalcache datastore and use its Permissions row action. Without Read the list refuses them before the row action is drawn. Read is enough; they change groups through the Security Group Manager, not by editing profiles.
Sign in as one of the managers, open My Domain's Users, use Security Groups on a Contoso user and confirm only Field Engineers is offered.

What goes wrong

"You do not have access to manage any security groups for this user." No row covers this person: the target group is not granted to any of the manager's groups, or the person is outside the login method or identity source limits.
A manager sees My Domain's Users but no Security Groups button. Their group lacks Read on the .users-externalcache datastore.
A manager put in the editor group through AD Group Mapping has no rights yet. Membership from the directory is read at sign-in, so they need to sign out and in again.
A limit of 0 in Limit to Identity Source stops a manager reaching AD users. 0 means local and social accounts only. Leave it empty for no limit.

Worked example

A managed service provider runs one installation for several client companies, each on its own Azure AD tenant. For each client it creates a managers group and adds a Security Group Managers row per group the client may assign, limited to Azure AD and that client's Azure AD Tenants row ID. Each client's IT lead can now move their own staff between groups from My Domain's Users, and cannot see or touch another client's people.

Recommendations

Delegate with limits wherever more than one directory signs in.
Give manager groups admin access level 1, never 2.
Grant My Domain's Users, not External / SSO Users, to delegated managers.
Hold manager membership in the directory through AD Group Mapping where you can.
Review Security Group Managers alongside your other permissions.

Groups for External and SSO Users

People who sign in through Active Directory, Azure AD, SAML or a social provider have no password on the platform, but they still need security groups. They have their own list in the Admin Panel, with its own Security Groups row action, and Active Directory users can also be given groups automatically from their AD groups. This article covers both routes and how they interact.

Where to find it

Admin Panel → User Administration:

External / SSO Users — every external identity, with the Security Groups row action
My Domain's Users — only the people who sign in from the same directory or provider as you
User Groups — the groups themselves

Architect Panel → Security:

AD Group Mapping — Active Directory groups that confer a security group at sign-in
Security Group Managers — who may assign groups to whom
Disabled User Accounts — identities refused at sign-in, whatever the provider says

The two lists

External / SSO Users lists every external identity the platform has seen: their cached profile, their approval state and their groups. It is granted to the Super Administrator group as standard.
My Domain's Users shows the same records filtered to the sign-in method and identity source of the person looking. One tile therefore means "my own directory" for every manager on every directory, which makes it the right tile to give a delegated manager.

An external person appears on these lists once they have signed in at least once, or once they have been provisioned by SCIM.

Giving an external user groups by hand

Open External / SSO Users (or My Domain's Users) and find the person.
Use the Security Groups row action. The Security Group Manager opens, saying how the person signs in.
Switch on the groups they need under User is Member and click Save Permissions.

The Security Groups action is shown for every external user, whether or not they are approved or currently able to sign in: managing someone's groups does not depend on whether they can sign in today. The Approve, Revoke, Decline and Change to Approved actions on the same list only appear when external user approval is switched on for the installation; see Single Sign-On Providers.

Giving Active Directory users groups automatically

AD Group Mapping links an Active Directory group to a security group. At each sign-in the platform reads the person's AD groups and grants every mapped security group. Membership is then managed where it belongs, in the directory, and somebody removed from the AD group loses the mapped group at their next sign-in.

Open AD Group Mapping and add a row linking the AD group, named as the directory reports it (for example CN=Finance,OU=Groups,DC=contoso,DC=com), to the security group.
Ask a member of that AD group to sign out and sign in again.
Open their Security Groups action. The mapped group is shown switched on and locked, naming the AD group that grants it.

Mapping applies to Active Directory sign-in only. For Azure AD, SAML and social logins, assign groups by hand, delegate it, or provision them with SCIM.

What goes wrong

Switching off a locked group is impossible. It is granted by AD. Remove the person from the AD group, or remove the mapping.
A banner says the directory could not be reached. The screen could not check AD, so groups granted by AD are shown as if not held. Local group changes still save correctly; do not "fix" AD-granted groups while the banner shows.
Somebody is missing from the list. They have never signed in and have not been provisioned.
A delegated manager sees everybody's users. They were given External / SSO Users instead of My Domain's Users. See Delegating Group Management.

Worked example

A college signs staff in with Active Directory and students with Azure AD. It maps the AD groups "Teaching Staff" and "Support Staff" to matching security groups, so staff access follows the directory. Students are assigned to course groups by each faculty's administrator, who has My Domain's Users and a Security Group Managers row limited to Azure AD and the student tenant. When a teacher moves into a support role and IT moves them between AD groups, their next sign-in carries the new group and not the old one, with nobody touching the platform.

Recommendations

Map AD groups wherever a group follows a directory role.
Change AD-granted access in AD, never on the platform.
Give managers My Domain's Users, not the full list.
Disable a departed identity on Disabled User Accounts if you cannot wait for the directory.