ServiceNow Universal Request Transfer and Assignment Group Routing: Service Sets and the universal_request Table

What is a Universal Request in ServiceNow?

A Universal Request is a wrapper ticket. The employee files one request, gets one number, and follows one record, while behind it the actual work happens on whatever record type the fulfilling department uses: an Incident for IT, an HR case for HR, a Requested Item for a catalog order. The UR is the front door and the primary ticket is the room the work happens in. That split is the whole point, because the alternative is what most organizations had before it, which is an employee filing a ticket in the wrong queue, being told to file it somewhere else, and starting over with a new number and no history. The UR record lives on the universal_request table, and that table extends task, which is why it carries assignment_group, assigned_to, state, short_description, and the rest of the fields any ServiceNow admin already knows. The inheritance matters more than it sounds, because it also means every dictionary override, business rule, and UI policy written against task applies here too. Two roles show up constantly in UR conversations. The routing agent is the tier 1 person who receives the request, decides which department owns it, and transfers it. The department agent is whoever works the primary ticket after the transfer. Almost every routing problem on this page is really a question about what information the routing agent has when they make that decision, and what the system does with it afterward.

What can be a primary ticket, and what cannot

This is the first hard boundary and it is worth checking before you design anything, because it can invalidate an entire plan. Universal Request works with the task table and tables that extend it, and nothing else. Incident, Problem, Change, Requested Item, catalog task, and HR case all qualify, because all of them extend task somewhere up the chain. A custom table built from scratch does not, and the way this surfaces is unhelpfully quiet: the table simply never appears in the reference field when you go to configure the Service. A ServiceNow Community thread on exactly this asked whether Universal Requests could be created from custom tables and got a one-line answer that has not changed since: it does need to be a table extending from task. If you have a home-grown request table that people file real work into, extending it from task is the prerequisite, not an optimization. Do that first. The related trap is a team that assumes Universal Request will unify absolutely everything an employee might ask for, including work that lives outside ServiceNow entirely. It will not, and it was never built to. Requests that get fulfilled in a different system still need routing there, which is the boundary where this page stops being about configuration and starts being about which tool owns which decision.

Service sets, services, and the one-Service-per-table rule

Here is the part that costs teams the most time, and it is genuinely counterintuitive. Routing in Universal Request is expressed as a two-level structure. A Service Set is a grouping, usually mapped to a department or a business area, and it is what the routing agent picks from when transferring. A Service sits inside a Service Set and defines the target: which table gets created and which assignment group receives it. So the obvious design, and the one everybody draws on the whiteboard, is a Service Set for IT Support containing a Service for Service Desk and a Service for Field Services, both producing Incidents, differing only in the group. Try to save the second one and it is refused. As a practitioner put it in the ServiceNow Community setup thread, out of the box there is a business rule, Unique Configuration for a table, that prevents creating more than one service for the incident table. A second team hit the same wall from the other direction while configuring service sets for IT and each of its child departments and found that only one department could be configured for Incidents. The rule is not a bug and disabling it is not the answer, however tempting that is at 6pm on a Friday. The supported pattern is to create a mapping configuration per department, set the receiving group inside the Create UR Information template on that mapping record, and add the child department groups to the Service Assignment Groups field on the Incident service configuration so they are selectable at all. One Service on Incident, several mappings underneath it. It is more moving parts than the whiteboard version, and it is the design that survives an audit. Plan for it up front, because retrofitting it after you have built ten Service Sets around the wrong assumption is a rebuild rather than an edit.

Why the assignment group dropdown is empty on a Universal Request

The symptom is precise and it makes people doubt their instance: open a UR, click the magnifier on Assignment group, and get an empty popup, while the identical field on an Incident lists every group you would expect. Nothing is broken. A group appears in the Universal Request assignment group picker only after the Universal Request type has been added to that group. That is the resolution the original poster reported on the ServiceNow Community developer forum, and it is consistent with how the Type field on sys_user_group is used elsewhere in the platform to filter which groups a given process will even offer you. There is a second cause worth ruling out at the same time, raised in the same thread by a responder: because universal_request extends task, a dictionary override on the assignment_group field can be replacing the reference qualifier you assume is running, so the query behind the picker is not the one you think it is. Check the override before you start adding types to two hundred groups. The wider lesson is one this site keeps running into from different directions. Group type gates far less than people expect in some places and far more than they expect in others, and it is never obvious which situation you are in until something comes up empty. Our breakdown of ServiceNow group types covers where the field genuinely controls behavior and where it is only a label, and group membership covers the related case where the group is correct and still nobody is in it.

Transferring a Universal Request to another department

Transfer is the action the whole product is named for, and it does two things at once: it creates or links the primary ticket in the receiving department, and it decides what that new record knows. The second half is configuration you own. Direct Transfer Configuration records define which source fields are copied onto which target fields when the transfer runs, so a UR handed to an HR case can carry the requester, the description, and anything else you map. A pattern that comes up repeatedly in community discussion is adding the business_service field to the UR form and mapping it through the Incident transfer configuration so that the support group attached to that business service becomes the assignment group on the resulting Incident. It is a good pattern because it moves the routing decision onto data the organization already maintains rather than onto the routing agent making a judgment call under time pressure. Then there is the failure everybody meets eventually. The transfer dialog offers an I am not sure department option for requests the routing agent cannot classify, and on many instances choosing it does nothing at all except spin. The browser console shows a 400 on the routePrimaryTicket API, and the cause is that the instance has no Universal Request Service Set marked as the universal set for the request to fall back to. The fix is a single record: go to universal_request_service_set, create a record named Universal Request, and set Universal Set to true. It ships with the plugin demo data, which is exactly why it is missing on the instances that were built properly without loading demo data, and why the teams most likely to hit it are the ones who did the install carefully.

Who owns the ticket at the end: needs resolution review

Routing gets the work to the right department. It does not decide who confirms the work was actually done, and Universal Request has an explicit setting for that which changes the shape of your queues. When Needs resolution review is checked on a Universal Request and the department agent closes the primary ticket, the UR does not close. It stays in the In Progress state and the state reason changes to Confirm Response, which signals the tier 1 routing agent to review what the department did before the requester sees it as finished. From there it forks. Accept moves the UR to Closed and the primary ticket stays closed as the department agent left it. Reject sets the UR to Action Required, and the primary ticket needs reopening or further work, with the department notified to pick it back up. This is a genuinely useful control for a service desk that owns the employee relationship, and it is also a queue that has to be staffed. Turn it on without assigning the review, and the predictable result is a growing pile of requests that every fulfilling team believes is finished and every requester believes is stuck, which is worse than not having the control at all. If you enable it, build the list of URs in In Progress with state reason Confirm Response, put a name on it, and watch its age. The same reasoning applies one level down, inside the receiving group: the group is right, and the work still waits because nothing decided which person in it picks the ticket up. That is the subject of ServiceNow assignment group routing, and it is where Advanced Work Assignment and the rest of the push-based options come in.

What Universal Request costs, and what it does not include

Licensing here is a common source of confusion, and it changed recently enough that older guidance is unreliable. Universal Request has generally not been sold as a standalone SKU. The capability is packaged inside other entitlements, which historically meant products such as ITSM and HRSD, with the richer Universal Request Pro variant associated with the higher ITSM tier rather than the base one. The reason to treat any specific tier name with caution is that ServiceNow repackaged its ITSM offerings in April 2026, replacing the long-standing Standard, Professional, and Enterprise structure with Foundation, Advanced, and Prime. Feature-to-tier statements written before that date, including most of the licensing threads you will find by searching, describe a tier structure that no longer exists under those names. The honest advice is the unglamorous kind: get the entitlement confirmed in writing by your ServiceNow account team against your current contract, and do it before you design a rollout that depends on Universal Request Pro behavior. What no ServiceNow tier includes is the part this page keeps circling back to. Universal Request decides which department and which group. It does not decide which teammate, and it has no view of work that lives outside the platform. Those two gaps are exactly where a routing layer earns its place.

Where native Universal Request stops and a routing layer starts

Native UR is the right tool for the problem it was built for, and if your situation is one department per target table, a routing agent who knows the org, and groups whose members reliably pick work up, you do not need anything else. Add the missing universal set record, add the UR type to your groups, map the transfer configurations, and you are done. The boundary is the point where the decision stops being about which team and starts being about which person. A group on a ticket says which queue, not which teammate, and ServiceNow leaves that second half to whoever opens the list first. That works when tasks are interchangeable and it fails when they are not, because the fastest person to claim work is very rarely the person with the most capacity, the right skill, or a calendar that is actually free this afternoon. Assigner sits beside ServiceNow rather than inside it and answers only that second question. It runs skills-based routing, workload balancing, round robin, weighted rotation, and availability rules as one engine, and it applies the same rules to work that never touches ServiceNow at all: support ticket routing, sales lead routing, and ops task assignment. Every assignment records the rule that fired and the people it considered, which is the part that makes it reviewable rather than a second black box on top of the first. It costs $12 per user per month billed yearly ($15/mo billed monthly), it is a companion rather than a live two-way sync, and it is built to help rather than to guarantee an outcome. If catalog work is the piece of this that keeps arriving unowned, the mechanics of that specific case are in ServiceNow catalog task assignment.

What is Universal Request in ServiceNow?

Universal Request is a parent ticket that gives an employee one record and one number for a request, while the actual work happens on a separate primary ticket in whichever department owns it. The UR record lives on the universal_request table, which extends task. A routing agent receives the request, picks the department, and transfers it, and the requester keeps following the original UR the whole time.

What is the universal request table name in ServiceNow?

The table is universal_request. It extends the task table, so it inherits assignment_group, assigned_to, state, short_description, and the other standard task fields, along with any business rules, UI policies, and dictionary overrides written against task. That inheritance is worth remembering when a field on the UR form behaves differently than the same field on an Incident.

How do you transfer a Universal Request to another department?

The routing agent uses the transfer action and picks a Service Set, which represents the department, and a Service inside it, which defines the target table and the receiving assignment group. Direct Transfer Configuration records control which fields are copied from the UR onto the new record. If the transfer dialog hangs on the I am not sure option, the instance is missing a service set marked as the universal set.

Why is the assignment group dropdown empty on a Universal Request?

Because the groups do not carry the Universal Request type. A group appears in the UR assignment group picker only after that type is added to the group record, which is why the same field is fully populated on the Incident form. Also check for a dictionary override on the assignment_group field, since universal_request extends task and an override can replace the reference qualifier you expect.

Can you create more than one Universal Request service for the same table?

Not out of the box. A business rule named Unique Configuration for a table prevents a second Service pointing at the same target table, so you cannot build one Service per department when several departments all fulfill on Incident. The supported approach is one Service on that table plus a mapping configuration per department, with the receiving group set in the Create UR Information template.

How do you route a Universal Request to different groups within one department?

Use mapping configurations rather than extra Services. Create a mapping per sub-team, set the assignment group inside the Create UR Information template on that mapping, and add the sub-team groups to the Service Assignment Groups field on the service configuration so they can be selected. This is the standard answer for department hierarchies with child departments fulfilling on a shared table.

What is universal_request_service_set used for?

It stores Universal Request service set configurations, and one of its records has a special job. When the routing agent chooses the I am not sure department option, the platform routes the request to the service set marked as the universal set. If no such record exists, the routePrimaryTicket API returns a 400 and the transfer dialog spins indefinitely. Creating a service set record with Universal Set set to true resolves it.

What does Needs resolution review do on a Universal Request?

It stops the UR from closing automatically. When the flag is checked and the department agent closes the primary ticket, the UR stays In Progress with the state reason set to Confirm Response, and the routing agent has to Accept or Reject. Accept closes the UR. Reject sets it to Action Required so the work goes back to the department. It adds a review queue that needs an owner.

Can a Universal Request be created from a custom table?

Only if that table extends task. Universal Request supports the task table and its extensions, which covers Incident, Problem, Change, Requested Item, catalog task, and HR case. A custom table built from scratch will not appear in the table reference field when you configure a Service. The prerequisite is to extend the custom table from task before attempting any UR configuration against it.

What is the difference between Universal Request and Universal Request Pro?

They are entitlement variants rather than separate products, with Pro historically tied to the higher ITSM tier and the base capability packaged in the lower one. Be careful with any tier names you read online, because ServiceNow repackaged its ITSM offerings in April 2026 into Foundation, Advanced, and Prime, so older comparisons describe tiers that no longer exist. Confirm your entitlement with your account team.

Is Universal Request licensed separately in ServiceNow?

It has generally not been sold as its own SKU. The capability is packaged within other product entitlements such as ITSM and HRSD rather than purchased on its own. Because the ITSM packaging changed in April 2026, the practical step is to have your ServiceNow account team confirm in writing what your current contract includes before you design a rollout around a specific Universal Request feature.

Does Universal Request assign work to individual agents?

No. Universal Request decides which department and which assignment group receives the request. Who inside that group picks the ticket up is left to the group queue, which usually means whoever opens the list first. That is fine when the work is interchangeable and costly when it is not. A routing layer such as Assigner adds rotation, workload, skill, and availability rules on top of the group and records why each person was chosen.