Loading

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

  1. Open All Users for a local account, or External / SSO Users for a single sign-on identity, and find the person.
  2. Use Manage Security Groups (or Security Groups on the external list). The Security Group Manager opens, naming the user and how they sign in.
  3. 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.
  4. 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.