Hi @NeethuB ,
if the user's Role tab is empty but they still appear to have inherited access, there are a few deeper layers to check.
1. Confirm Group Removal
You mentioned the user is removed from all groups — double-check this via:
- User record → Groups related list
- Also check Group Memberships viasys_user_grmember table
var gr = new GlideRecord('sys_user_grmember');
gr.addQuery('user', '<user_sys_id>');
gr.query();
while (gr.next()) {
gs.print('Group: ' + gr.group.name);
}If this returns results, the user is still in a group.
2. Check Role Inheritance via Group Roles
Even if the user is removed from groups, roles might still appear due to cached inheritance. To verify:
- Navigate to User → Roles tab
- Click “View → All Roles” to see inherited ones
- Use the “Inherited From” column to trace source
3. Flush Role Cache
Sometimes roles persist due to caching. Run this in Background Scripts:
var user = new GlideUser('<user_sys_id>');
user.flushRoles();This forces ServiceNow to recalculate the user's roles.
4. Check for Scripted Role Assignments
Roles might be assigned dynamically via:
- Business Rules
- Script Includes
- ACLs with gs.hasRole() logic
Search for any custom logic that assigns roles based on conditions.
5. Check Impersonation or Session Artifacts
If you're testing via impersonation:
- Clear impersonation
- Log out and back in
- Use “Show Security Debug” to trace role checks
Since you're detail-oriented and proactive:
- Consider building a reusable script to audit inherited roles and their sources
- You can also create a Flow Designer action to flush roles post-group removal for safer automation
If it is helpful, please hit the thumbs button please mark the answer as correct based on the impact!!
Kind Regards,
Shaik Mohammed Mustaq
