ServiceNow Assignment Group vs Support Group Explained

In ServiceNow, an assignment group and a support group are the same kind of record. Both are rows on sys_user_group. The difference is not the group, it is the field pointing at it: on tables that extend Task the reference is labelled Assignment group, because a task is assigned to a group, while on CMDB tables the reference is labelled Support group, because a configuration item is supported by a group rather than assigned to one. Once that clicks, most of the confusion around these two terms resolves, and the remaining questions turn out to be about which of the four CMDB group fields you should have populated.

The reason this trips people up is that both terms get used two ways at once. There is the platform meaning, which is the field label described above, and there is the local convention almost every organization layers on top, where an assignment group means the first line that picks up the call and a support group means the second or third line that owns the underlying service. Both usages are legitimate. Only one of them is something the platform enforces, and mixing them up in a design conversation is how teams end up with two group hierarchies that nobody can reconcile.

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

They are the same record type in different contexts. Every group on the platform, whatever it does, is a row on sys_user_group. There is no separate assignment group table and no separate support group table. What varies is which field on which table holds the reference.

On any table that extends Task, which covers incident, request, change, problem, and every custom task table you have built, the field is assignment_group and it answers the question of who owns this piece of work right now. It is a current-state field. It changes as the ticket moves, and each change increments the reassignment count.

On CMDB tables, the field is support_group and it answers a different question: who supports this thing, permanently, regardless of whether any ticket exists. A database server has a support group whether or not anybody has an incident open against it. That is an attribute of the asset, not a state of a task.

So the practical distinction is duration and subject. Assignment group is a transient property of work. Support group is a durable property of a thing. They point at the same pool of groups, and they very often point at the same group, which is exactly why the difference is easy to miss until you have to write a report against one of them.

What is the ServiceNow support group table?

There is no support group table either. The support group is a reference field on the configuration item record, most commonly cmdb_ci.support_group, and the value it holds is a sys_id pointing at a row on sys_user_group. The same is true of the equivalent field on service offerings.

Two related tables matter more than most people expect, because neither is a field on the group. Membership lives in sys_user_grmember, a many-to-many join between users and groups, which is why exporting sys_user_group on its own returns groups with no people in them. Roles granted through a group live in sys_group_has_role. If a report of support groups comes back looking empty, this is nearly always the reason rather than a data problem.

Support group vs managed by group in ServiceNow

This is the question that follows almost immediately, because the CMDB does not have two group fields, it has several, and they are genuinely distinct. Here is the family and what each one is for.

The clean mental model is that support group is reactive, managed by group is proactive, and assignment group is momentary. Support group receives the pager. Managed by group decides when the thing gets patched. Assignment group is simply where the ticket happens to be sitting at this second.

Most instances do not need all five populated, and filling fields because they exist is a reliable way to create data nobody maintains. Pick the ones your processes actually read. If nothing in your instance queries change group, leave it empty rather than populating it with a guess that will be wrong in six months. The one field almost every organization does need is support group, and it is worth treating as a required attribute with an accountable owner, in the same way the group that manages an item's lifecycle is usually also the group that has to answer for what it costs to keep running at budget time.

How the CI support group becomes the ticket assignment group

This is the bridge between the two concepts, and it is the part that makes the distinction operationally important rather than merely semantic.

ServiceNow ships a business rule called Populate Assignment Group based on CI/SO. When the configuration item or service offering on a task changes, it reads the support group from that referenced record and writes it into the task's assignment group. That is the whole mechanism. The durable property of the thing becomes the initial owner of the work.

Three consequences follow, and each one shows up as a support ticket somewhere.

First, it runs server side, on save. The assignment group appears after the record is written, not at the moment the user picks the CI. That reads as a bug to anyone expecting the form to update as they type, and it is not one.

Second, the quality of your routing is capped by the quality of your CMDB. If a third of your configuration items have an empty support group, a third of the tickets raised against them populate nothing, and no amount of rule writing changes that arithmetic. When teams ask how to auto populate the assignment group, the honest answer is frequently that the mechanism is already there and the data underneath it is thin. There is more on the full set of population mechanisms and how they interact in auto populating the ServiceNow assignment group.

Third, this rule is one of several things that can write the same field, and assignment rules will not overwrite an assignment group that already holds a value. So a perfectly correct assignment rule can appear to do nothing simply because the CI rule got there first. That interaction is the most common cause behind ServiceNow assignment rules not working, and it is worth checking before rewriting any conditions.

Which group field should you actually use?

A short decision path handles nearly every case.

If you are describing a piece of work, use assignment group. It is the only one of these fields that is supposed to change, and it is the field every task-based report, SLA, and notification is already built around.

If you are describing a thing in the CMDB and you want incidents about it to reach the right people, populate support group. This is the field the out-of-box automation reads, so it is the one that turns CMDB effort into routing accuracy.

If you are describing who keeps a thing healthy over its life, populate managed by group, and accept that it will often be a different team from the support group. The service desk that resolves a printer incident is rarely the team that decides when the printer is replaced.

If your organization uses the words to mean first line and second line, write that convention down somewhere and make sure everyone knows it is your convention rather than platform behaviour. The platform will not enforce it, will not report on it, and will not stop somebody putting an L1 group in a field your process treats as L2.

Common mistakes with support groups

The mistakes here repeat across instances with unusual consistency.

Creating a parallel set of groups is the expensive one. Because the terms sound different, teams sometimes build a support group for a team that already has an assignment group, ending up with two records for one team, split membership, and reports that undercount both. They are the same table. Reuse the group.

Leaving the group email field populated without checking the notification is the quiet one. When a group record has an email address, group notifications go to that single address instead of to the members, unless the notification's include members option is also enabled. It looks exactly like notifications having stopped.

Deactivating a group without moving its work is the one that leaves things stranded. Deactivation hides the group from pickers, and does nothing at all to the open records still pointing at it. Find them first.

Letting the manager field go stale is the slow one. The manager is who reviews membership, and a group whose manager left the company two years ago is a group that has been quietly accumulating people who no longer do the work. The full set of fields on the group record, including why the Type field behaves like a list rather than a choice, is covered in the ServiceNow assignment group reference.

Where the group stops being the answer

Everything above settles which group owns a piece of work. None of it settles which person is going to do it, and that second question is where most of the actual pain lives.

A ticket lands in a group queue and distribution becomes self-service. In practice that means the fastest and most conscientious agents take the most work, the specialists get cherry-picked for the interesting problems, and whoever joined last week takes what is left. Nothing in the group record was ever trying to prevent that. ServiceNow's own answer is Advanced Work Assignment, which routes to available people rather than to groups, though it needs the plugin, an ITSM, CSM, or HRSD subscription, a workspace containing the Agent Inbox, and agents who keep their presence states current.

Assigner sits beside ServiceNow rather than replacing it. Once the group is known, it rotates work to a named owner using true round robin, weighted round robin, live workload, skills, and availability, runs the same engine over sales leads and ops tasks as over tickets, and records the rule and the candidates behind every assignment so a routing dispute is a lookup rather than an investigation. Pricing is published at $12 per user per month. Our ServiceNow routing alternative page makes the comparison in full, including the cases where staying entirely native is 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.