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.