ServiceNow Assignment Group: Table, Best Practices, History, and Types

What is the ServiceNow assignment group table?

The answer is shorter than most people expect: there is no assignment group table. Every group on the platform, whether it routes incidents, approves changes, supports configuration items, or exists purely to carry a role, is a record on sys_user_group. What changes is the label on the field pointing at it. On tables that extend Task the reference is called Assignment group, because a task is assigned to a group. On CMDB tables the same reference is usually labelled Support group, because a configuration item is supported by a group rather than assigned to one. Plenty of organizations layer their own meaning on top, using an assignment group as the first line that takes the call and a support group as the second or third line that owns the underlying service. That convention is theirs, not the platform's. Two related tables matter as much as the group record itself and are easy to miss. Membership lives in sys_user_grmember, a many-to-many table joining users to groups, which is why an export of sys_user_group on its own contains no people. Roles granted through the group live in sys_group_has_role. If you are writing a report, an integration, or a cleanup script and it returns groups with nothing in them, this is almost always the reason.

Why your group does not show up in the assignment group picker

This is the single most common assignment group support question, and the cause is nearly always the Type field rather than anything to do with the group being broken. Type is not a choice field. It is a list of references to the sys_user_group_type table, which means one group can carry several types at once, and it also means the value behaves like a list everywhere you touch it. Read it in a client script and you get a comma-separated string of 32 character sys_ids rather than the names you expected, which is why so many client-side attempts to check group type appear to work in testing and then fail in production. The reliable pattern is to let the server evaluate it, either through a reference qualifier on the field or through an asynchronous GlideAjax call that returns a simple answer to the form. The picker itself is filtered by a reference qualifier on the assignment_group dictionary entry or a dictionary override, and many instances carry a customized one restricting the list by type, by whether the current user is a member, or by the configuration item on the record. So a group that exists, is active, and has members can still be invisible on a form because a qualifier written three years ago excludes it. Check the dictionary override on that specific table before assuming the group record is at fault, since the qualifier can differ between Incident, Change, and a custom table pointing at the same groups.

ServiceNow assignment group best practices

Most group hygiene advice comes down to keeping the number of groups small enough that a human can reason about them, and keeping accountability attached to each one. Give every group an active manager and treat that as a hard requirement rather than a nice to have, because the manager is who reviews membership and who the platform can reference in approvals and escalations. Review membership on a schedule, quarterly is the common recommendation, since groups accumulate people who moved teams and rarely lose them. Grant permissions to groups rather than to individuals, which is the difference between an access review you can complete and one you cannot. Be cautious with parent groups: hierarchy looks like the obvious way to model an organization, but nesting groups for role inheritance or reporting makes it genuinely difficult to answer who holds which role, and the usual guidance is to avoid leaning on it. Name groups after the work they do rather than after the team that currently does it, because the work outlives the org chart. Decide deliberately whether a group has an email address, since filling that field sends notifications to the shared mailbox instead of the members unless the include members option is also set. And before deactivating a group, find the open records still pointing at it, because deactivation hides the group without moving the work. Once groups are clean, the remaining question is how work gets from the group to a person, which is where round-robin assignment and workload balancing do the part ServiceNow groups do not.

How to report on ServiceNow assignment group history

A group stamp is a current value, so the record only ever tells you where a ticket is now, not where it has been. There are three ways to recover the history and they are not equally good. The straightforward one is the reassignment count field, which increments each time the assignment group changes. It is cheap and it tells you a ticket has bounced, but it does not tell you between whom. The strong option is the metric_instance table. ServiceNow ships a metric definition for assignment group, and when it is active you get one metric instance record for every group a record passed through, including how long that group held it. That is what makes real questions answerable: which group holds work longest before passing it on, how often the service desk reassigns rather than resolves, which group is the true first owner. Performance Analytics builds on the same data for reassignment trend reporting. The option to avoid is sys_audit. It does contain the old and new values of every audited field change, but reporting against it is widely discouraged because of its size and shape, and sys_history_line is the friendlier place to look when you need to read what happened on a single record. If you find yourself building this reporting because assignment disputes keep coming up, that is worth noticing on its own: the underlying need is usually not history, it is knowing why an item was routed the way it was at the moment it happened.

Where assignment groups stop being enough

Groups are the right abstraction for ownership and a poor one for fairness, and the gap shows up the same way in most organizations. A rule stamps the group, the work lands in a shared queue, and distribution to individuals becomes self-service. In practice that means the fastest and most conscientious agents take the most work, specialists get cherry-picked for the interesting tickets, and the person on their first week takes whatever is left. Nothing in the group record prevents any of it, because the group record was never trying to. ServiceNow's own answer to this is Advanced Work Assignment, which is genuinely good at routing to available people, though it needs the plugin, the right subscription, a workspace containing the Agent Inbox, and agents who maintain presence states. Its two strategies also stop short of weighting, so a part-time agent and a senior engineer take the same share. Assigner sits beside ServiceNow rather than replacing it. It routes support tickets, sales leads, and ops tasks through one engine with skills-based routing, availability routing, and weighted rotation included, publishes its price at $12 per user per month, and shows the rule and the candidates behind every assignment. Our ServiceNow routing alternative page makes the comparison in full, including the cases where staying native is clearly the right call. It is a companion rather than a live two-way sync, and it is built to help rather than to guarantee an outcome.

What is an assignment group in ServiceNow?

An assignment group is a group of users that owns a piece of work, referenced from the Assignment group field on any table that extends Task. It is a record on the sys_user_group table, the same table behind every other group on the platform. Assigning a task to a group puts it in that group's queue, but it does not pick an individual owner, which is a separate step.

What is the ServiceNow assignment group table name?

The table is sys_user_group. There is no separate assignment group table: every group on the platform lives on sys_user_group, and Assignment group is simply the label used for the reference field on Task tables. Group membership is stored on sys_user_grmember, roles granted by the group on sys_group_has_role, and group types on sys_user_group_type.

What is the difference between an assignment group and a support group in ServiceNow?

They are the same kind of record, labelled differently by context. On tables that extend Task the reference field is called Assignment group, because a task is assigned to a group. On CMDB tables the same reference is labelled Support group, because a configuration item is supported rather than assigned. Many organizations also use the terms to separate first line ownership from the team that owns the underlying service, but that is convention rather than platform behaviour.

What are the assignment group types in ServiceNow?

Group types are records on the sys_user_group_type table and are used mainly to filter which groups appear in which pickers. Common examples include itil for service desk groups, along with types for catalog, approval, and change work, and organizations add their own. The important detail is that Type is a list of references rather than a single choice, so a group can hold several types at once.

Why is my assignment group not showing in the dropdown?

Usually a reference qualifier is filtering it out rather than anything being wrong with the group. The assignment_group field carries a qualifier, often set through a dictionary override that differs per table, which commonly restricts the list by group type, by current user membership, or by the configuration item on the record. Check that qualifier first, then confirm the group is active and has the expected type values.

How do you track assignment group history in ServiceNow?

Use the metric_instance table. ServiceNow ships an assignment group metric definition that creates one record for each group a task passes through, including how long that group held it, which is what makes duration and reassignment reporting possible. The reassignment count field on the record gives a quick indicator of bouncing. Reporting directly against sys_audit is discouraged, and sys_history_line is easier to read for a single record.

Should you use parent groups in ServiceNow?

Generally not for granting roles or for reporting hierarchy. Nesting groups makes it hard to answer who actually holds a role, since permissions arrive indirectly, and it complicates membership reviews. A flat structure with clear names and an accountable manager on each group is easier to maintain. Parent groups are best kept for the rare case where the hierarchy genuinely reflects how work escalates.

Why are group members not receiving ServiceNow notifications?

Check whether the group record has an email address filled in. When that field is populated, group notifications are sent to that single address instead of to the individual members. To notify both the shared mailbox and every member, the include members option has to be enabled on the notification as well. A group with an email address and include members left off looks exactly like notifications being broken.