How access reaches a user
Access is easiest to support when users receive capability through governed group membership instead of many direct roles.
The simple model
A user represents a person who can access the platform. A group brings users together for a shared responsibility. A role grants permission to use platform capabilities.
- User: who is using the platform
- Group: which team the user belongs to
- Role: what the user is allowed to do
How roles reach a user
A role can be assigned directly to a user, but group-based assignment is easier to govern. When a role is assigned to a group, every active group member receives that role through inheritance.
- Prefer group-based role assignment
- Avoid unnecessary direct roles
- Review group membership regularly
Interview scenario
If a fulfiller moves from one support team to another, update the group membership instead of repeatedly changing individual roles. This keeps access aligned with team responsibility and makes auditing easier.
Implementation steps
Follow these steps in a personal developer or sub-production instance. Validate backend names and choice values before using the solution in production.
Create a responsibility-based group
WHERE: User Administration > GroupsUse a business name such as Network Support, not a person's name. Add manager, email and description.
Assign the minimum role to the group
WHERE: Group Roles related listAdd only the role required for the team's work. Review any roles contained inside it.
Add users through membership
WHERE: Group Members related listAdd active users and confirm manager approval. Avoid assigning the same role directly to each user.
Test with impersonation
WHERE: Impersonate UserOpen the required module and records as a real group member. Also test a user who should not have access.
Review and remove access
WHERE: Access review processDeactivate obsolete membership and document temporary access expiry.
Find active members of a support group
Run as a background script in a safe sub-production instance. The script reads group membership; it does not change access.
var member = new GlideRecord('sys_user_grmember');
member.addQuery('group.name', 'Network Support');
member.addQuery('user.active', true);
member.query();
while (member.next()) {
gs.info(member.user.getDisplayValue());
}How to test it
- 1Group member receives the required module
- 2Non-member is denied
- 3Direct URL is protected by ACL
- 4Inactive member no longer receives access
- 5Contained roles are understood
- 6Temporary access is removed on time
Common mistakes
- Creating one role for every team
- Assigning roles directly to hundreds of users
- Using UI visibility as security
- Deleting groups before moving open tasks
- Testing only with admin
Can you explain this solution under pressure?
Practice real scenarios covering this topic, architecture decisions, troubleshooting and security.
Explore more implementation guides or request the next topic.