ServiceNow CSA: Managing Users, Groups, and Roles

The three tables

• Users - sys_user. Each user has a user_name, email, active flag, and optional fields like web_service_access_only for integration accounts.
• Groups - sys_user_group. Groups organize people for assignment, approval, and role distribution. Membership lives in sys_user_grmember.
• Roles - sys_user_role. Roles are the unit of authorization; ACLs reference roles.

Users can hold roles directly (sys_user_has_role) or inherit them through group membership. Roles may also contain other roles, so granting a parent role implicitly grants its children.

Key behaviours

Roles are strictly additive. There is no "deny" role and no negative permission - a user's effective access is the union of every role they hold, directly or via groups. Consequently, "remove access" means unassigning a role or removing the user from a group. Group roles are applied to members, and the standard way to remove group-inherited roles is to remove membership, not to edit the role.

Best practice and traps

Assign roles to groups, and users to groups, rather than assigning roles user-by-user; this makes auditing and onboarding manageable. Questions often suggest the opposite ("assign the itil role to each technician individually") as a distractor. Another trap: confusing assignment groups (routing work on task records) with user groups generally - they are the same table, but an assignment group is simply a group referenced from a task's assignment_group field.

Worked example

A new service desk analyst needs to work incidents. Correct approach: add the user to the existing Service Desk group that already holds itil. Incorrect: granting itil directly to the user, which creates an unmanaged role assignment that survives a transfer.