ServiceNow Group Types: The Group Type Table, the Type Field, and Assignment Group Types

What is a group type in ServiceNow, and what does it actually control?

A group type is a record on the sys_user_group_type table. The Type field on sys_user_group points at it. That is the whole data model, and it is simpler than the confusion around it suggests.

What it controls is the part that surprises people: on its own, nothing. Type is a categorization field. The platform does not read it and change behavior. A group with no type can be stamped on an incident, receive a catalog task, approve a change and own a knowledge article, exactly like a group carefully typed for each of those things. This is not an accident or a gap, it is the design. ServiceNow gives you a categorization axis and leaves it to you to decide what it means.

The evidence for this is worth citing because it is unusually direct. ServiceNow community threads asking what the out-of-box group types are for note that the product documentation explains how to build a reference qualifier that limits an assignment group field to specific group types, but does not list any built-in functionality the out-of-box types have. Long-running forum answers describe Type as a field for categorization and filtering, used to tell ten similar groups apart, to drive assignment group fields and flows, or simply to count how many groups of a kind exist.

So the practical rule is this. Type is an input to configuration you write, not a switch you flip. If you set type on four hundred groups and change nothing else, you have made a tidy report and no functional difference at all.

The out-of-box group types, and why the list is so short

On a baseline instance the group types most commonly present are catalog, itil and survey. Plugins add more, so a mature instance with ITSM, CSM, Field Service and Security Operations activated will show a longer list, and no two instances agree. That variability is the first reason to look at sys_user_group_type in your own instance before writing anything that depends on the list.

The three baseline types map to the three oldest reasons ServiceNow needed to tell groups apart. itil marks groups that work tickets, which is why it is the type nearly every reference qualifier ends up filtering on. catalog marks groups involved in request fulfilment. survey marks groups involved in survey distribution. None of them enforce those boundaries.

Published ServiceNow group best-practice guidance is fairly blunt that the out-of-box types are not very good, and recommends defining your own. A commonly recommended scheme separates security, for groups that exist to grant roles, from process groups that actually work items: catalog, incident, problem, change, vulnerability, knowledge and approval. The same guidance argues that every group should carry at least one type, that every reference field pointing at a group should carry a qualifier based on type, and that changes to the type list need central governance rather than being open to any admin. That last point is the one teams skip and regret, because a type list nobody owns grows a duplicate within a year.

The Type field is a list, not a choice, and that changes how you script it

This is where developers lose an afternoon. Type looks like a choice field on the form and behaves like one when you click it, but underneath it is a glide_list that references sys_user_group_type. Two consequences follow, and both bite.

First, a group can hold more than one type at once. That is legitimate and often correct: a service desk group that both works incidents and fulfils catalog requests should carry both types. But it means any logic written as though type were single valued is wrong. A condition that tests type equals itil still matches a group carrying itil and catalog, which is usually what you want. A script that reads the type and compares it to a single expected value does not, and it will fail on exactly the groups that are configured most carefully.

Second, reading the field returns sys_ids, not names. A client script or a getValue call on Type comes back with a comma-separated string of sys_ids, so a developer debugging a client script sees something like a long hexadecimal string where they expected the word itil. Server side you can dot-walk or run a GlideRecord against sys_user_group_type to resolve names. Client side you need a client callable Script Include reached through GlideAjax, because the names are simply not present in the value you were handed.

The practical guidance: filter on sys_id in conditions and qualifiers rather than on display names, and never assume the field holds exactly one value.

How to show only itil groups in the assignment group field

This is the configuration that makes type mean something, and it is the reason most people arrive at this topic in the first place. The Assignment group field on Task and its child tables is a reference to sys_user_group with no type filter, so out of the box every active group in the instance is selectable, including HR groups, approval groups and the group somebody made for a project three years ago.

The fix is a reference qualifier on the field. The simple form is a condition built in the condition builder, Type is itil, which the platform stores as a query on the type sys_id. Written out, it looks like type=1cb8ab9bff500200158bffffffffff62, the baseline sys_id for the itil type on most instances. Verify that sys_id against sys_user_group_type in your own environment rather than copying it blindly, because instances that were built from a non-standard baseline or migrated between versions do not always match.

Two refinements are worth adding while you are in there. Combine the type filter with active=true, since a type qualifier alone still offers deactivated groups. And if the rule you need is more complicated than a static condition, for example showing only groups the current user belongs to, or only groups that support the affected configuration item, use an advanced reference qualifier that calls a Script Include. The Script Include runs a GlideRecord query server side and returns a list of group sys_ids, which the field then uses as its available choices.

Apply the same thinking to every other group reference on the platform. The approval group field should be filtered to approval groups, the catalog task assignment group to catalog groups, and so on. A type scheme with qualifiers on one field out of nine is a type scheme that has not been implemented.

The tree picker known error that silently ignores your qualifier

If you build a reference variable on sys_user_group inside a catalog item, write a careful reference qualifier, and then watch users pick groups the qualifier should have excluded, you have probably hit a documented ServiceNow known error rather than a mistake of your own.

ServiceNow has published a known error covering the case where a reference qualifier on a tree picker for the sys_user_group table, used in a service catalog variable, does not restrict the selection. The tree_picker attribute changes how the reference field renders, presenting the group hierarchy as a browsable tree, and the qualifier is not applied to that tree in the way it is applied to a standard reference lookup.

This matters more than a normal edge case because the tree picker is attractive exactly where filtering matters most. Somebody enables it so requesters can browse a large group hierarchy, which is a sensible thing to want on an instance with hundreds of groups, and the very size of that hierarchy is what made the qualifier necessary. The result is a catalog item that looks well governed and is not.

The workaround is to avoid the tree picker on filtered group variables and use a standard reference field with the qualifier, accepting a plainer lookup, or to validate the selection after the fact with a catalog client script or a flow condition that rejects a group of the wrong type. Neither is elegant. Knowing the behavior is a product issue rather than a configuration error is worth an hour of not debugging your own qualifier.

A group type scheme that survives three years

The failure mode is predictable enough to design against. Year one, somebody defines a clean set of types and qualifies the main assignment fields. Year two, a project needs a group urgently, creates it untyped, and it works fine because nothing enforces type. Year three, the picker is full of untyped groups again, half the qualifiers have been removed by people who could not find a group they needed, and the model is decorative.

Four things prevent that. Make type mandatory on the group form, so an untyped group cannot be created in a hurry. Restrict who can create records on sys_user_group_type, so the type list does not grow a near-duplicate every quarter. Put a qualifier on every group reference field rather than the obvious one, because a single unfiltered field is enough to reintroduce the wrong group into the data. And report on it: a scheduled report listing active groups with no type, or with a type that no qualifier anywhere uses, turns a slow decay into a short monthly task.

Two more design notes from the same body of practice. Keep role-granting groups separate from working groups, because mixing them is what makes access reviews impossible to complete, and the security type exists for exactly this separation. And remember that type does not cascade down a parent and child hierarchy. Like membership, it is set per group, so a neatly typed parent tells you nothing about the groups beneath it and a qualifier on type will not find children through their parent.

When group type stops being the right tool for the job

Type answers one question well: which groups belong in this picker. It is a filtering and governance device, and inside that scope a qualified type scheme is genuinely valuable and worth building.

What it cannot do is decide who works the item. A perfectly typed instance still stamps a queue and stops. Somebody in the group still has to pick the ticket up, and on a busy morning that is whoever is fastest rather than whoever is fairest or best suited. Type has no concept of who is on shift, who is at capacity, who holds the certification the item needs, or who took the last three of these. Those are the questions that actually determine whether work gets done well, and no amount of group modeling reaches them.

That is the line where a routing layer earns its place. Assigner sits beside ServiceNow rather than replacing it. ServiceNow stays the system of record and keeps the incident, the CMDB, the workflows and the reporting. Assigner decides who, using true circular round robin, weighted rotation for part-time staff, enforced workload limits, skill matching and live availability, and it records the rule, the candidates it considered and the reason for each assignment. When somebody asks why a P2 went to a junior engineer, the answer is one line rather than a reporting project.

The two are complementary rather than competing. Keep the type scheme for governing which groups can be chosen. Use a routing engine for choosing the person inside the group.

What are the ServiceNow group types?

On a baseline instance the group types usually present are catalog, itil and survey. Plugins add more, so an instance running ITSM, CSM and Field Service will show a longer list. All of them live on the sys_user_group_type table, and none of them enforce behavior by themselves. Check sys_user_group_type in your own instance rather than assuming a standard list, because the contents vary with the plugins activated.

What table stores ServiceNow group types?

Group types are records on sys_user_group_type. The Type field on sys_user_group references that table. Because the reference is a glide_list rather than a single reference, one group record can point at several type records at once, and the stored value is a comma-separated list of sys_ids rather than a single value.

What is the group type field in ServiceNow?

Type is a field on sys_user_group that categorizes the group by referencing sys_user_group_type. It looks like a choice field on the form but is a list field underneath, so a group can carry more than one type. Its purpose is filtering and categorization: reference qualifiers, User Criteria, flows and reports read it, but the platform does not change behavior based on it by itself.

What does the itil group type do in ServiceNow?

By itself, nothing. It is a label marking the group as one that works ITIL process records. It becomes functional when a reference qualifier on an Assignment group field filters on it, which is what makes only itil groups appear in that picker. Without that qualifier, a group typed itil and a group with no type at all are equally selectable.

What is the catalog group type in ServiceNow?

The catalog type marks groups involved in service catalog request fulfilment, so that catalog task assignment fields and catalog variables can be filtered to show only relevant groups. As with itil, the type does not restrict anything on its own. The restriction comes from a reference qualifier on the catalog variable or from a flow that looks up the fulfilment group by type.

What are assignment group types in ServiceNow?

Assignment group types is not a separate feature, it is the group Type field seen from the perspective of the Assignment group picker. Teams use type to mark which groups should be assignable, then add a reference qualifier to the Assignment group field so only those types appear. The type alone does not make a group assignable, because the Assignment group field is an unfiltered reference to sys_user_group out of the box.

How do I show only itil groups in the assignment group field?

Add a reference qualifier to the Assignment group field with the condition Type is itil, which stores as a query on the itil type sys_id, commonly 1cb8ab9bff500200158bffffffffff62 on a baseline instance. Verify that sys_id in your own sys_user_group_type table first. Combine it with active=true, because a type filter alone still offers deactivated groups.

Why is my group still showing in the assignment group list?

Because type does not control selectability, the Active field does. An unfiltered Assignment group field is a plain reference to sys_user_group and shows every active group in the instance regardless of type, including untyped ones. Either add a reference qualifier that filters on type, or deactivate the group. If a qualifier is already in place and being ignored, check whether the field uses the tree_picker attribute, which ServiceNow has documented as not applying reference qualifiers.

Can a ServiceNow group have more than one type?

Yes. Type is a glide_list, so a group can hold several types at once, and a service desk group that both works incidents and fulfils catalog requests should carry both. The consequence is that any logic treating type as a single value is unreliable. A condition testing whether type contains itil is safe, while a script comparing the whole field to one expected sys_id will fail on multi-typed groups.

Why does the group type field return sys_ids instead of names?

Because it stores references, not text. Reading Type client side gives a comma-separated string of sys_user_group_type sys_ids, since the display names are not part of the stored value. Server side you can dot-walk to the name or query sys_user_group_type directly. Client side you need a client callable Script Include reached through GlideAjax to resolve names, and filtering on sys_id is more reliable than filtering on display name in either case.

What are ServiceNow group type best practices?

Make type mandatory on the group form, keep role-granting security groups separate from process groups that work items, and put a reference qualifier on every field that references a group rather than only the obvious Assignment group field. Restrict who can add records to sys_user_group_type so the list does not grow duplicates, and run a scheduled report on active groups with no type. Published ServiceNow group guidance recommends defining your own types rather than relying on the baseline ones.

Do group types cascade from a parent group to its children?

No. Type is set per group record and does not roll down the parent and child hierarchy, so a correctly typed parent tells you nothing about the groups beneath it and a qualifier filtering on type will not reach child groups through their parent. This matches how membership behaves, which also does not roll up or down the hierarchy, and it is a common source of a rule that resolves to a group with nobody in it.