- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2025 09:08 AM
Hi team, I’m encountering an unusual situation with how groups and roles are working in ServiceNow. When I added users to the risk_manager_group, they had access to add/edit risk records. However, I’m now trying to assign only the specific roles they need and since the group contains three roles, I initially assumed that one of them would grant "edit" or "admin" permissions.
But it seems that all three roles are primarily related to "read" permissions, as none of them provide the ability to add/edit records. To investigate, I tested by assigning each role individually to a user to see which one grants the necessary add/edit permissions, but none of them allowed this access. That is where it gets confusing since I expected a specific role to grant add/edit level of access.
Is it possible that a combination of roles could grant extra access/permissions? I initially thought that each role would have a clearly defined and separate scope of access.
Let me know if this makes sense or if you have any insights into what might be happening here. Thank you in advance!
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2025 12:30 PM
Each role should and does have a separate scope of access. I would try to start a new session (e.g. a new incognito window) when testing each individual role to ensure that caching isn't causing problems with access. You can also use Security Debugger (System Diagnostics > Debugging > Debug Security Rules) to check which ACLs are being met that grant the write access.
It's unlikely, but I suppose there is a chance that one of the ACLs is performing an isMemberOf(group) check via script rather than looking at roles. You'll probably want to start by looking at the write ACL for your risk table!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2025 12:30 PM
Each role should and does have a separate scope of access. I would try to start a new session (e.g. a new incognito window) when testing each individual role to ensure that caching isn't causing problems with access. You can also use Security Debugger (System Diagnostics > Debugging > Debug Security Rules) to check which ACLs are being met that grant the write access.
It's unlikely, but I suppose there is a chance that one of the ACLs is performing an isMemberOf(group) check via script rather than looking at roles. You'll probably want to start by looking at the write ACL for your risk table!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2025 01:50 PM
Hi @jcmings ,
I found the culprit role thanks to you.
Thank you again for your help!