ServiceNow Group Membership Table: Group Members, Membership History, and Audit

What is the ServiceNow group membership table?

It is sys_user_grmember, labelled Group Member. It is a plain join table: one row per user and group pair, with a user field referencing sys_user and a group field referencing sys_user_group. Both hold sys_ids. That is the whole schema that matters, and it is why the table is easy to script against and easy to misread. The confusion almost always comes from the two tables having similar names. sys_user_group is the group itself: its name, manager, parent, type, email, and description. sys_user_grmember is who is in it. If you are building a report and you cannot find members, you are probably on the group table. One practical wrinkle worth knowing before you plan a report: the Group Member table is not always selectable from the related list conditions picker when you report on groups, which is why so many membership reports get built the other way round, starting from sys_user_grmember and grouping by Group.

Why your group membership history does not exist

This is the single most expensive thing about the table and almost nobody finds out until they need it. Removing somebody from a group deletes the row. There is no active flag, no end date, and no tombstone. The moment an admin clears a name off the Group Members related list, the only evidence that person was ever in that group is gone. So the question people actually arrive with, some version of "was this person in the network team when that change was approved", cannot be answered from sys_user_grmember at all. Not with a filter, not with a script, not with a report. The table is a snapshot of right now and it has always been a snapshot of right now. Worse, the fix is not retroactive. Switching on auditing today gives you history from today. Nothing before that comes back. If your organization has any obligation to prove historical access, an SOX control, an access review, a security investigation after the fact, the time to turn auditing on was before you needed it, and the second best time is now.

How to audit ServiceNow group membership changes

There are two workable approaches and one that looks like it should work and does not. The straightforward one is table auditing. Enable auditing on sys_user_grmember, and from that point every insert and delete is recorded. You read it back from the Audit History tab, and the entries you are looking for carry a Label or Type of relation, which is how a removed membership shows up. It is the least code and the most complete. The second approach is a business rule on Group Member, running after insert and delete, writing a row into a custom logging table with the user, the group, the action, the timestamp, and who did it. Teams choose this when they want the log in a shape they control, when they want to keep it after a table cleanup, or when they cannot get approval to audit a system table. Both are fine. Pick one and do it. The approach that disappoints is sys_audit_role. It does log role grants and revocations, including ones inherited through a group, which sounds like exactly what you want. But it only sees membership changes that changed somebody's roles. A group that grants no roles, which describes most assignment groups, produces nothing in it at all. It is an access audit, not a membership audit, and treating it as the latter leaves gaps you will not notice until an auditor does.

Parent and child groups do not share members

The group hierarchy in ServiceNow is real, and it does much less than the org chart on screen implies. Membership does not roll up. Adding a person to a child group does not make them a member of the parent group, and adding them to the parent does not put them in the children. There is no setting that turns this on. The consequence shows up in routing and it is ugly: somebody designs a tidy tree, points an assignment rule at the parent group because that is the level the process is written at, and the rule resolves to a group with no members. Work sits in a queue nobody is subscribed to, and because the group exists and is active, nothing in ServiceNow flags it as wrong. If you need a parent group that behaves like the union of its children, you have to build it. The usual options are a business rule that mirrors membership on insert and delete, a scheduled job that reconciles the tree nightly, or a deliberate decision to put only the child group managers in the parent, which is a much smaller list to keep honest. Whichever you pick, write it down, because the next admin will assume inheritance works. There is one place hierarchy does behave the way people expect, and the inconsistency catches people out: User Criteria based on a group does include members of subgroups. So access to a knowledge base or a catalog item can cascade down the tree while assignment does not. Two features, one hierarchy, two behaviors.

How to check group membership in a script

Server side, the shortest correct answer is gs.getUser().isMemberOf(). It accepts either a group name or a sys_id, so both gs.getUser().isMemberOf('Network Operations') and the sys_id form work. Two limits: it only ever evaluates the currently logged in user, and it is server side only. To test membership for somebody else, or for an arbitrary user and group pair, query the table directly with a GlideRecord on sys_user_grmember, adding a query on user and one on group, both by sys_id, then checking whether next() returns anything. That is two lines and it is the pattern to reach for by default, because it works for any user rather than just the session. Client side is where people lose an afternoon. isMemberOf() is not available in a client script, and there is no reliable client-side group check that does not go to the server. The supported route is a Script Include marked client callable, exposing something like isUserInGroup(userId, groupId), called from the client with GlideAjax. Make it asynchronous. A synchronous call blocks the form while the round trip happens, and on a slow connection that is exactly the lag users report as ServiceNow being slow. And if the check is only ever about the logged-in user and the group grants a role, consider checking the role client side instead, which needs no round trip at all.

Include members, exclude manager, and the fields that are not about membership

Three fields on the group record catch searches that are looking for something else entirely, and two of them are hidden on a default form. Include members is a notification setting, not a membership setting. When a group has a Group email address filled in, notifications addressed to the group go to that mailbox. Ticking Include members sends the email to the individual members as well. It has nothing to do with hierarchy, nothing to do with child groups, and nothing to do with who can be assigned work. If you arrived at this page searching for how to make a group include the members of another group, that is the field you were probably hoping for, and it is not it. Exclude manager is the matching control on the other side: it keeps the group manager out of those notifications, which teams switch on once a manager complains about the volume. Group email is the field that quietly changes the default. Leave it blank and ServiceNow emails every member individually regardless of the Include members setting, which is the state most groups are actually in and the reason so many people have a ServiceNow filter in their mail client. If notifications are going to the wrong people, check those three fields before you touch membership, because membership is usually not the problem.

Dynamic membership, empty groups, and the cleanup nobody schedules

ServiceNow has no native query-driven group membership. There is no rule on sys_user_group that says "everyone in this department, kept current". Membership is a set of explicit rows, and the ways teams keep them current are all imports or automation: an LDAP or Active Directory import that syncs group membership on a schedule, a scheduled job that reconciles membership against a field on the user record such as department, location, or manager, or a business rule on sys_user that maintains membership when someone transfers. Any of those is better than the alternative, which is that nobody maintains it and the list slowly stops matching the team. The routine worth putting in a calendar is finding groups with nobody in them. Build the report from the membership side: a report on sys_user_grmember grouped by Group tells you every group that has at least one member, and anything on the group list that does not appear has none. Cross-check that against groups still referenced by an active assignment rule and you have your real problem list, because an empty group nobody routes to is harmless and an empty group with a live rule pointed at it is a queue that silently swallows work. While you are there, check for the opposite failure: members who are inactive users. Those rows are not deleted when somebody is deactivated, so a group can look healthy and contain four people who left.

When the group is the wrong unit of assignment

Everything above is really one problem wearing different hats. ServiceNow assigns work to a group, and a group is a list of names with no idea who is on holiday, who already has eleven open incidents, who has the skill the ticket actually needs, or who left in March. Membership is doing a job it was never designed for, which is why keeping it accurate feels like so much work: it is the only lever you have. Assigning to a person changes the shape of the problem. Assigner sits beside ServiceNow, reads current open work per person, the skills each item needs, and whether that person is available at all, then routes the work to somebody who can start it and records which rule made the decision along with the candidates it passed over. Group membership becomes a description of your team rather than the mechanism that decides who works tonight, and an inactive user or a stale row stops being an outage waiting to happen. It is a companion designed to help you decide the assignee rather than a live two-way sync into your instance, the AI assists while the rules stay yours. Pricing is published per user, so the honest comparison is against the admin hours you currently spend keeping lists correct.

What is the ServiceNow group member table name?

The table is sys_user_grmember, labelled Group Member. It holds one row per user and group pair, with a user field referencing sys_user and a group field referencing sys_user_group, both storing sys_ids. The group record itself lives in sys_user_group, which is the table people usually land on first when they are actually looking for members.

How do I check group membership in ServiceNow?

In a server script, use gs.getUser().isMemberOf(), which accepts a group name or a sys_id but only evaluates the logged-in user. For any other user, run a GlideRecord query on sys_user_grmember with a query on the user sys_id and one on the group sys_id, then check whether next() returns a row. In the interface, open the group and read the Group Members related list.

How do I see ServiceNow group membership history?

You cannot, unless auditing was enabled on sys_user_grmember before the change happened. Removing a member deletes the row outright, so there is nothing left to query. With auditing on, the Audit History tab shows the insert and delete records, and removed memberships appear with a Label or Type of relation. Auditing does not backfill, so history starts the day you switch it on.

How do I audit group membership changes in ServiceNow?

Enable table auditing on sys_user_grmember, which records every insert and delete and is the least work. If you need the log in your own format, or cannot audit a system table, write an after business rule on Group Member covering insert and delete that logs the user, group, action, timestamp, and who made the change to a custom table. Do not rely on sys_audit_role for this.

How do I check group membership client side in ServiceNow?

Not directly. isMemberOf() is server side only and there is no reliable client-side equivalent. Create a client callable Script Include with a method such as isUserInGroup(userId, groupId) and call it asynchronously with GlideAjax. Keep it asynchronous: a synchronous call blocks the form during the round trip. If the group grants a role and you only care about the current user, check the role instead and skip the call.

Do child group members belong to the parent group in ServiceNow?

No. Group membership does not roll up the hierarchy, and no setting enables it. Somebody in a child group is not a member of the parent, so an assignment rule pointed at a parent group can resolve to nobody at all. If you need that behavior, build it with a business rule or a scheduled reconciliation job. User Criteria based on a group does include subgroup members, which is why the inconsistency surprises people.

What does the Include members field on a ServiceNow group do?

It is a notification setting. When a group has a Group email address, notifications sent to the group go to that mailbox; ticking Include members sends them to the individual members as well. It has nothing to do with group hierarchy or with who can be assigned work. If the Group email field is blank, members are emailed individually anyway, whatever the checkbox says.

Does ServiceNow support dynamic group membership?

Not natively. There is no query-driven membership rule on the group record, so membership is always a set of explicit rows in sys_user_grmember. Teams get the same effect with an LDAP or Active Directory import that syncs membership on a schedule, a scheduled job that reconciles membership against a user field such as department or location, or a business rule that maintains membership when someone transfers.

How do I add a user to a group with the ServiceNow REST API?

Create a record on the Group Member table. POST to /api/now/table/sys_user_grmember with a JSON body containing the user sys_id and the group sys_id, for example a user field and a group field. Removing somebody is a DELETE on that membership record, which is worth remembering because that delete is exactly what destroys the history if auditing is not already on.

How do I export ServiceNow group members to Excel?

Open the Group Member list, filter it to the group or groups you want, add Group and User as columns, then right-click the list header and choose Export, then Excel or CSV. Exporting from the group record itself gives you the groups rather than the people, which is the usual reason an export comes back with the wrong thing in it.

How do I find ServiceNow groups with no members?

Report from the membership side rather than the group side. A report on sys_user_grmember grouped by Group lists every group that has at least one member, so any group on the sys_user_group list that does not appear has none. Cross-check the result against groups still referenced by an active assignment rule, because an empty group with a live rule pointed at it is a queue that quietly swallows work.

Why is the active members count on my ServiceNow group empty?

Those count fields are calculated rather than stored as part of the membership itself, so they can sit blank or stale on instances where the calculation has not run or has been customized. Treat them as a convenience rather than a source of truth. If the number matters, count rows in sys_user_grmember for that group, filtered to active users, since deactivating somebody does not remove their membership row.