user-group-administration

Users, Groups and Roles

acl-security teaches the rules. This teaches the things the rules apply to. Without it an agent asked to "add Sam to the change team" writes a background script against sys_user_grmember, which works right up until it silently creates a second membership row.

Four tables

Table	Holds
sys_user	people
sys_user_group	groups
sys_user_grmember	one row per (user, group) membership
sys_user_has_role	one row per (user, role) grant — direct and inherited

There is no list of members on the group and no list of roles on the user. Both are join tables, and both are where the work happens.

Order of operations

Group before membership, role before grant. Every one of these is a reference field with no auto-create behind it:

// 1. the group
const grp = await snow_role_group_manage({ action: "create_group", name: "Database — Change",
                                           manager: managerSysId, description: "Owns DB change approvals" })

// 2. then people into it — takes sys_id, username OR email, so no lookup step
await snow_manage_group_membership({ action: "add", group_identifier: "Database — Change",
                                     user_identifier: "[email protected]" })

// 3. and a role onto the group, so membership grants it
await snow_role_group_manage({ action: "assign_role", role: roleSysId, group: grp.sys_id })

snow_manage_group_membership checks for an existing membership before inserting, which a hand-written GlideRecord.insert() does not. Duplicate sys_user_grmember rows do not break access — they break removal, because the remove path deletes one row and the user is still a member.

Inherited versus direct: the part that bites

A role reaches a user two ways, and sys_user_has_role holds both: