ServiceNow Group Roles: The Group Roles Table, Role Inheritance, and sys_group_has_role

What is the ServiceNow group roles table?

The group roles table is sys_group_has_role. It is a plain many to many join: one column points at a group on sys_user_group, another points at a role on sys_user_role, and a row means that group grants that role. On the group form it surfaces as the Roles related list, which is where most admins meet it without ever learning the table name.

Two other columns matter more than the join itself. inherits marks a row that arrived from a parent group rather than being added by hand, and granted_by records which group it came from. Together they are how you separate roles somebody deliberately gave a group from roles the hierarchy pushed onto it. A filter of granted_by is not empty and inherits is true lists every inherited group role on the instance, which is the fastest way to see how much of your access model is being generated rather than designed.

The companion table is sys_user_has_role, and it is easy to confuse the two. sys_group_has_role holds the design: what a group is entitled to. sys_user_has_role holds the result: what a person actually ended up with, one row per user and role, with an inherited flag that is true when the role arrived through a group or through another role rather than being granted to the person directly. Reports about entitlement should read the group table. Reports about exposure should read the user table.

Do ServiceNow child groups inherit roles from the parent group?

Yes. If a group has a parent, the child group inherits the roles of the parent group, and the members of that child group end up holding those roles. This is the documented and expected behavior, and it is the single most useful thing about the group hierarchy: put the role every network engineer needs on a parent network group, and the eight child groups underneath it stay correct without anybody maintaining eight sets of roles.

It is also where the surprises live, because the inheritance is produced by a business rule rather than resolved at read time. The rows are real rows, written when something changes. Three consequences follow, all of them reported repeatedly in ServiceNow community threads.

First, it can time out. One instance with a large number of groups reported the propagation script hitting a timeout after 296 seconds, with the result that members of child groups did not receive some parent roles. Nothing about that failure is visible on the group form. The parent shows the role, the child shows the relationship, and the user simply does not have the access.

Second, a newly created child group does not always pick up the parent roles. Admins report creating a group, setting the Parent field, and finding no roles inherited. The workarounds that circulate are equally telling: clear the Parent field, save, and set it again, or remove the role from the parent and add it back. Both work by forcing the rule to run again, which is a strong hint that the trigger, not the logic, is what failed.

Third, role management plugins interfere with it. Community answers point at the Contextual Security role management plugins as a cause of inheritance not behaving as expected, and separate threads report inheritance breaking on instances that extended sys_user_group or sys_user_grmember with custom tables. If you have extended either table, treat inheritance as something to test rather than something to assume.

Roles cascade, membership does not, and that gap is where routing breaks

This is the asymmetry worth writing on a whiteboard, because almost nobody expects it and it explains a whole category of ServiceNow problems.

Roles flow down the hierarchy. Membership does not flow at all. Put the itil role on a parent group and every child group inherits it, so every person in every child group can work tickets. Assign an incident to that same parent group and the work is offered to the direct members of the parent group, which on a well designed hierarchy is often nobody, because the parent exists purely as an organizing node.

So the parent group looks, on paper, like the right place to send work. It is the group with the roles. It is the group with the tidy name. It has fifty people underneath it. And a ticket sent there sits untouched over a weekend because the roster resolving behind it is empty. The ServiceNow group membership page covers the membership half of this in detail, including the inconsistency that User Criteria based on a group does include subgroup members, so catalog and knowledge access cascades while assignment stubbornly does not.

The practical rule is to keep the two models apart on purpose. Use the hierarchy for entitlement, where cascading is a feature. Assign work only to leaf groups that have real members, never to organizing parents. And check the assumption directly rather than trusting the org chart: open the parent group, look at the Group Members related list, and count. If the number is zero, nothing you route there will ever be worked.

Why granted_by is empty, and how to find where a role really came from

Sooner or later somebody asks the reasonable question: this user has the itil_admin role, which group gave it to them? There is a field that looks built for exactly that. On sys_user_has_role the granted_by field is a reference to sys_user_group and is meant to name the granting group. On most modern instances it is blank.

The reason is not a bug in your data. granted_by, along with included_in_role and included_in_role_instance, was deprecated by the Contextual Security: Role Management V2 plugin and is not maintained any more. Community answers from ServiceNow practitioners are explicit that these fields are no longer populated by the platform and that granted_by survives mainly for Role Delegation. Teams routinely open a support case about the empty column and are told, in effect, that the column is not coming back.

So reconstruct the answer instead. It takes two queries and no plugin.

Start on sys_group_has_role, filtered to the role in question. That gives every group entitled to it, including the inherited rows, where granted_by is maintained and does tell you which parent the entitlement came from. Then take that group list to sys_user_grmember and filter membership to the user. The intersection is your answer: the groups that both grant the role and contain the person. If the intersection is empty, the role did not come from a group at all, and you are looking at either a direct grant or a role contained inside another role.

Do this as a saved report rather than ad hoc. Access reviews come round on a schedule, and the reconstruction is the same every time.

Inheritance count, de-duplication, and the import that quietly skips rows

If two different groups both grant a user the same role, ServiceNow does not write two rows. The Contextual Security: Role Management V2 plugin, identified as com.glide.role_management.inh_count, exists to prevent duplicate entries in sys_user_has_role for inherited roles, and it does it with an inheritance count column. The second grant increments the count on the row that is already there.

This is correct behavior and it is the answer to a question that generates a lot of support tickets: why did removing this person from a group not remove the role? Because another group still grants it, and the count went from two to one rather than the row disappearing. The role is still legitimately theirs.

The consequence people trip over is on data loads. The system property glide.role_management.use.inh_count controls this behavior, and when it is true the plugin owns the contents of sys_user_has_role. You should not import records into sys_user_has_role while that property is on. The table is derived, not authoritative, and an import fights the code that maintains it. This is what sits behind the "Skipping record for table sys_user_has_role" messages that appear in import and update set logs and look, at first glance, like a permissions problem.

Load the source of truth instead. Import group membership into sys_user_grmember and group entitlements into sys_group_has_role, and let the platform derive the user role rows itself. It is slower to think about and it is the only version that stays correct.

Roles that stay behind after you remove somebody from a group

The expected behavior when a user leaves a group is that the inherited roles that came with that group disappear. Often they do not. Admins report rows persisting on sys_user_has_role with inherited still set to true, long after the membership row is gone.

Check the legitimate explanation first, because it is the common one: another group still grants the role, and the inheritance count simply decremented. Query sys_group_has_role for the role, cross-check the remaining groups for that user, and if you find a second source, there is nothing to fix.

If there is no second source, you are looking at the real failure, which community reports attribute to the out of box Group Member Delete business rule not always clearing inherited roles, particularly where the inherited flag is stuck. The workaround that circulates is a two step: set inherited to false first, then delete the record, because the deletion path behaves differently for a row still marked inherited. ServiceNow support can also run a recalculation available with the Role Management V2 plugin, which audits and corrects inheritance discrepancies across the instance and is the right call if this is widespread rather than a handful of rows.

Whatever the fix, treat orphaned inherited roles as a governance finding rather than a nuisance. Access that outlives the reason for it is exactly what an auditor is looking for, and unlike most audit findings this one has a query you can run in a minute.

Grant roles to groups, and keep role groups separate from work groups

The design guidance is consistent across every serious ServiceNow group model, and it comes in two halves.

The first half: grant roles to groups, not to users. A direct grant on a user is a decision with no owner, no reason attached, and no natural review point. A grant on a group can be explained, because the group has a name, a manager and a purpose. When someone changes teams, the entitlement follows the group change instead of being remembered by whoever happens to know.

The second half is the one teams skip: the groups that grant roles should usually not be the groups that receive work. The moment an assignment group also carries a meaningful role, the roster becomes an access decision. Adding a contractor to the queue so they can pick up tickets for a fortnight also grants whatever the group grants, and quietly stops being reversible when nobody remembers to remove them. Published ServiceNow group best practice recommends a separate security group type for groups whose job is granting roles, kept distinct from process groups that work items. Our page on ServiceNow group types covers how to make that distinction actually enforce something, which requires a reference qualifier, because type on its own gates nothing.

One shortcut deserves a warning. user_admin is the role people reach for when a team lead wants to manage their own roster without a full admin, and it is far broader than it sounds: on any instance where groups grant roles, the ability to edit group membership is the ability to grant those roles. Delegating group management through the Manager field with targeted ACLs is the narrower and safer pattern.

What is the ServiceNow group roles table?

The group roles table is sys_group_has_role. Each row links a group on sys_user_group to a role on sys_user_role and means that group grants that role. It appears on the group form as the Roles related list. The inherits and granted_by columns on the same table distinguish roles added by hand from roles pushed down by a parent group.

What is sys_group_has_role in ServiceNow?

sys_group_has_role is the many to many table joining groups to roles. It records entitlement, meaning what a group is allowed to do. The separate sys_user_has_role table records the result for individual people, with an inherited flag set to true when the role reached them through a group or through another role instead of a direct grant.

Do ServiceNow groups inherit roles from parent groups?

Yes. A child group inherits the roles of its parent group, and members of the child group receive them. Inherited rows on sys_group_has_role carry inherits set to true and a granted_by pointing at the source group. The propagation is done by a business rule, so it can fail quietly on large instances or on newly created child groups.

What is the difference between groups and roles in ServiceNow?

A role is a permission, checked by ACLs to decide what somebody can see and do. A group is a collection of people, used to grant roles in bulk and to own work through assignment groups. Roles answer what you may do, groups answer who you are with. The recommended practice is to grant roles to groups rather than to individual users.

How do I add a role to a group in ServiceNow?

Open the group record in User Administration, then Groups, scroll to the Roles related list, and use Edit to pick the role. The platform writes the row to sys_group_has_role and then propagates it to the current members as inherited rows on sys_user_has_role. On a large group that propagation is asynchronous, so give it a minute before concluding it failed.

How do I add a role to multiple groups in ServiceNow?

Open sys_group_has_role directly as a list, which lets you insert rows for many groups without opening each group form. For a repeatable bulk change, a background script that queries the groups you want and inserts a row per group is safer, because it can be reviewed before it runs. Avoid importing into sys_user_has_role, which the platform maintains itself.

How do I check what roles a user has in ServiceNow?

Open the user record and look at the Roles related list, which shows every role including inherited ones. For an instance wide view, filter sys_user_has_role by user. The inherited column tells you whether the role was granted directly or arrived through a group or a containing role, which is the distinction that matters during an access review.

What is the ServiceNow role inheritance count?

The inheritance count records how many times the same role has been granted to a user through different sources. The Contextual Security: Role Management V2 plugin uses it instead of writing duplicate rows in sys_user_has_role. When a second group grants a role the user already holds, the count increments. When one of those groups is removed, the count decrements and the role correctly remains.

Why does a user still have a role after being removed from the group?

Usually because a second group still grants it, so the inheritance count decremented rather than the row being deleted. If no other group grants it, the out of box Group Member Delete business rule has failed to clear the inherited row. The reported workaround is to set inherited to false and then delete the record.

Can a user have a role in ServiceNow without being in any group?

Yes, and it is common. Roles contain other roles, so a user granted a broad role automatically holds every role inside it, shown as inherited with no group behind it. Direct grants written straight to the user do the same thing. Both are why an empty Groups related list does not mean an empty Roles related list.

What is the ServiceNow group admin role?

There is no role named group admin. The role people mean is user_admin, which allows managing users and groups without full admin rights. Treat it carefully. On an instance where groups grant roles, anyone who can edit group membership can effectively grant those roles, which makes user_admin a privilege escalation path rather than a light delegation.

Why is the granted_by field empty on sys_user_has_role?

Because it was deprecated. The Contextual Security: Role Management V2 plugin retired granted_by along with included_in_role and included_in_role_instance, and the platform no longer maintains them, so the column reads blank. To find the source of a role, query sys_group_has_role for that role and intersect that group list with the memberships recorded for the user on sys_user_grmember.