Security Attribute `RoleExplicit` description

NS
Kilo Sage

‎09-01-2026 07:08 AM

Hello,

 

I came across something misleading in the OOB Security Attribute `RoleExplicit`. The description of it is 

> User has the specified role explicitly, that is, it is present in the sys_user_has_role table.

NS_0-1788271164680.png

 

 

This seems to be completely wrong. The attribute seems to consider the sys_user_has_role.inherited instead.

In this case my user gets the role through a group membership -> "it is present in the sys_user_has_role table.". But the access is denied because the role is inherited=true

NS_1-1788271302200.png

 

 

Grant the role directly, and the user gains access as you would expect:

NS_2-1788271565317.png

 

 

This security attribute was discussed also in this community post, but it doesn't address the description. Hope someone finds this helpful or doesn't trust the description of the security attribute thanks to this!

 

Labels:
0 Helpfuls
  • 755 Views
1 REPLY 1

kmohammed
Mega Guru

yesterday

You are reading the behavior correctly, and the description is indeed misleading as written.

 

The word to focus on is "explicitly". In ServiceNow, a role granted through a group still creates a row in sys_user_has_role - but with inherited=true. A role granted directly to the user creates a row with inherited=false. RoleExplicit tests the second case only: the user holds the role directly, not through group membership.

 

That is why your two cases behave the way they do:

- Role via group membership: sys_user_has_role row exists, but inherited=true, so RoleExplicit denies.

- Role granted directly: sys_user_has_role row exists with inherited=false, so RoleExplicit passes.

 

You can verify it yourself in the list: filter sys_user_has_role by the user and the role, and look at the Inherited column.

 

The practical consequence is about which check to use:

- If the intent is "anyone who has this role by any path, including through a group, may do this", use the plain role check, not RoleExplicit.

- Use RoleExplicit only when the grant must be personal to the user - where group membership alone should not confer the privilege.

 

And yes, the description should say "directly assigned (inherited=false)" rather than just "present in the sys_user_has_role table". That wording is what makes the group case look like a bug, when it is actually the attribute working as its name suggests.

0 Helpfuls