ServiceNow Catalog Task Assignment Group: sc_task Routing, Table, States, and Unassigned Catalog Tasks

What is a catalog task in ServiceNow?

A catalog task lives on the sc_task table, carries the SCTASK prefix, and represents one piece of fulfillment work underneath a Requested Item. The chain is worth stating plainly because the assignment problem lives in the joints between its links. A user orders something and a Request (REQ, table sc_request) is created as the container. Under it sits one Requested Item (RITM, table sc_req_item) per catalog item ordered. Under each RITM, the workflow or flow attached to that catalog item creates one or more catalog tasks, and those are the records a human actually opens and works. sc_task extends the task table, which is where it inherits assignment_group, assigned_to, state, short_description and the rest of the familiar fields from. That inheritance is also the source of a lot of confusion, because REQ and RITM inherit exactly the same fields and therefore look assignable even in catalogs where nobody ever intended to assign them. A common piece of community guidance is to report on the catalog task table to see which group actually did the work, precisely because the group on the parent records is so often decorative.

Why the Fulfillment group field routes nothing

This is the single most expensive misunderstanding in the service catalog, and it is entirely reasonable to fall for. Open a catalog item and there is a field labeled Fulfillment group. It stores a reference to a sys_user_group record. On the back end it is the group field on sc_cat_item. Everything about it says routing. Out of the box it performs none. Setting it does not populate the assignment group on the Request, on the Requested Item, or on any catalog task created underneath. It is a piece of metadata about the item, and it stays that way until you write something that reads it. The community workaround has been the same for years and it is one line, placed in a run script inside the workflow on sc_req_item: current.assignment_group = current.cat_item.group;. That copies the item Fulfillment group onto the RITM assignment group. Notice what it does not do: it does not reach the catalog tasks. Those are separate records created by a separate step, and they need their own answer. If you want the RITM group to flow down to its tasks, the reliable place to do that is a before insert business rule on sc_task that reads the parent RITM, ordered below 1000 so it runs before the assignment engine gets involved. Our write-up on ServiceNow assignment rules execution order covers exactly where that order number puts you in the save sequence and why 1000 is the number that matters.

The one fork that decides whether your assignment rules ever run

ServiceNow assignment rules live on sysrule_assignment, apply to the task table and anything extending it (so sc_task qualifies), and are evaluated from the lowest order number upward, with the first matching rule applied and evaluation stopping there. The property that governs catalog tasks is narrower and less advertised: an assignment rule fills an empty assigned_to or assignment_group and will not overwrite a value that is already there. Follow that through to the catalog and you get a hard fork with no middle. If the Create Catalog Task action, or the old workflow catalog task activity, sets an assignment group at insert, then the record is already assigned by the time the engine looks at it, and every assignment rule you wrote for sc_task is skipped for that task, forever, silently. If the action sets no group, the task inserts empty and the engine gets its turn, so your assignment rules run and a well-written catch-all can pick it up. Both designs are defensible. Mixing them is what hurts, and mixing them is the default outcome, because the choice is made independently inside each catalog item by whoever built it. Before you write another assignment rule for sc_task, list the catalog items whose task-creation step sets a group, because on those items the rule you are about to write can never fire. A default value on the sc_task assignment_group field has the same effect for the same reason: at insert the field is no longer empty.

Why catalog tasks come back unassigned after a deployment

The pattern is specific enough to diagnose from the symptom alone. Routing works perfectly in development. The update set moves to test or production. Catalog tasks start arriving with an empty assignment group and nobody changed a rule. The cause is almost always a sys_id that does not exist in the target instance. As one ServiceNow Community contributor put it, if the sys_id is not the same between the instances, the group will disappear when tasks are created. Group records created by hand in each environment get different sys_ids, and a reference field that points at a sys_id with no matching record does not error. It stores nothing and moves on, which is why this fails silently rather than loudly. Three habits prevent it. Look the group up by name at runtime instead of pasting an ID, so the flow resolves whatever group exists in the instance it is running in. If you must pin a specific group, put its sys_id in a system property and read the property, so the value is one record to correct per environment rather than a hunt through flow inputs. And move the group records themselves in the update set, or create them with matching sys_ids, so the reference has something to land on. Two smaller variants of the same failure are worth knowing. In Flow Designer, using the Template value type to set assignment_group and other fields has been identified in community troubleshooting as a cause of values that appear correct in the flow context and never reach the record. And in workflow scripts, a group sys_id pulled from the scratchpad can carry whitespace that quietly invalidates the reference, which is why the accepted fix in those threads is task.assignment_group = workflow.scratchpad.amsGroup.toString().trim(); rather than a direct assignment.

Catalog task states, and the two that hide work

Catalog task state values are inherited from the task table and the out-of-box set is small: 0 Pending, 1 Open, 2 Work In Progress, 3 Closed Complete, 4 Closed Incomplete, and 5 Closed Skipped. Two practical notes. First, these are integers, and integrations that send the label rather than the number are a routine source of updates that appear to do nothing. Second, they are customizable, so before you build a report or an integration on them, confirm the real values on your instance by right-clicking the State field and choosing Show Choice Lists, or by filtering the dictionary where element is state and table is task. The states that hide work are Pending and Closed Skipped. Pending is the state a task sits in while it waits on something, and a pending task with no assignment group is invisible twice over: it is not in anybody list and it is not in the open backlog most dashboards count. Closed Skipped is worse for reporting honesty, because a skipped task closes the RITM path without the work being done, and a catalog whose skip rate is climbing usually has a routing problem rather than a demand problem. If you build one report out of this page, build the list of sc_task records where state is in 0, 1 or 2 and assignment_group is empty, and give it an owner.

Where to put the group: RITM, SCTASK, or both

There is a reasonably settled community convention here and it is worth adopting rather than rediscovering. Leave the Request assignment group blank, especially when a single REQ carries several RITMs, because a group on the container tells you nothing about who did what. Populate the RITM assignment group with the group that owns the item end to end, which gives reporting a reliable non-empty field and gives escalations somebody to call. Populate the catalog task assignment group with the group that performs that specific step, which is the only one of the three that has to be right for the work to get done. The reason to do both rather than one is that they answer different questions. The RITM group answers who owns this request. The SCTASK group answers who is doing this piece. On a multi-step item, hardware provisioning followed by an access grant followed by a desk booking, those are three different groups and one RITM, and collapsing them loses the routing entirely. Where this convention gets expensive is the point at which the SCTASK group is correct and the work still does not move, because a group is not a person. Assignment inside the group is where ServiceNow assignment group behavior and group membership stop agreeing with each other, and a parent group with no direct members is the classic case of a correctly routed task that reaches nobody.

When native catalog routing is enough, and when it is not

It is enough more often than a vendor page usually admits. If your catalog items each have one fulfillment group, that group has real members, and the flow sets the group by lookup rather than by pasted sys_id, you are done. Add a catch-all assignment rule for the items that set no group, schedule the unassigned-task report, and go build something else. The honest boundary is the point where the decision stops being about the item and starts being about the person. A group on a catalog task says which team, not which teammate, and ServiceNow leaves the second half to the group queue and whoever clicks first. That is fine when tasks are interchangeable and expensive when they are not, because the fastest person to claim work is rarely the person with the most room for it. Native catalog routing also has no view of anything outside ServiceNow, so the leads your sales team is chasing and the ops work living in spreadsheets stay unrouted. That is the gap Assigner fills, beside ServiceNow rather than instead of it. One engine covers support ticket routing, sales lead routing, and ops task assignment, with skills-based routing, workload balancing and enforced limits included at $12 per user per month billed yearly ($15/mo billed monthly), and every assignment records the rule it used and the candidates it considered. 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 a catalog task in ServiceNow?

A catalog task is a record on the sc_task table, numbered SCTASK, that represents one piece of fulfillment work under a Requested Item. When a user orders a catalog item, ServiceNow creates a Request, a Requested Item under it, and then one or more catalog tasks under that RITM through the item workflow or flow. The catalog task is the record a fulfiller opens and works.

What is the catalog task table in ServiceNow?

The catalog task table is sc_task. It extends the task table, which is where it inherits assignment_group, assigned_to, state, short_description and the other standard task fields. Its parent is the Requested Item table sc_req_item, which in turn sits under the Request table sc_request. Reporting on who actually performed catalog work is done against sc_task rather than the parent records.

Does the Fulfillment group on a catalog item set the assignment group?

No. The Fulfillment group field on a catalog item is stored as the group field on sc_cat_item, and nothing reads it out of the box. It does not populate the assignment group on the Request, the Requested Item, or any catalog task. Copying it across is a manual step, most commonly a workflow run script containing current.assignment_group = current.cat_item.group on the sc_req_item table.

Why are my catalog tasks unassigned in ServiceNow?

Usually one of three causes. The task-creation step sets no assignment group and no assignment rule matches the record. Or a hard-coded group sys_id in a flow input or workflow script does not exist in this instance, so the reference silently resolves to nothing. Or the catalog item Fulfillment group was set and assumed to route, which it never does. Check which of the three applies before writing another rule.

Do assignment rules work on catalog tasks?

Yes, because sc_task extends the task table and assignment rules apply to task and task-extended tables. The important limit is that an assignment rule only fills an empty assigned_to or assignment_group and will not overwrite an existing value. If your Create Catalog Task action or workflow activity already sets a group at insert, or the field carries a default value, the assignment rule never fires on that record.

How do you set the assignment group on a ServiceNow catalog task?

Set it in the step that creates the task. In Flow Designer that is the Assignment group input on the Create Catalog Task action, and in the older workflow editor it is the catalog task activity, optionally scripted as task.assignment_group. If you would rather the assignment engine decide, leave that input empty and write an assignment rule on sc_task, since the rule only runs while the field is still empty.

What are the catalog task state values in ServiceNow?

The out-of-box values inherited from the task table are 0 Pending, 1 Open, 2 Work In Progress, 3 Closed Complete, 4 Closed Incomplete, and 5 Closed Skipped. Integrations must send the integer rather than the label. These choices are customizable, so verify them on your own instance by right-clicking the State field and selecting Show Choice Lists before you build a report or an integration on them.

What is the difference between a catalog task and a request item?

A Requested Item (RITM, table sc_req_item) is one catalog item that somebody ordered. A catalog task (SCTASK, table sc_task) is one step of work required to fulfill that item, and a single RITM can have several. The convention most teams settle on is to put the owning group on the RITM for reporting and escalation, and the performing group on each catalog task, because that is the record the work happens on.

Why did my catalog task assignment group disappear after a deployment?

Almost certainly a sys_id that does not exist in the target instance. Group records created separately in each environment get different sys_ids, and a reference field pointing at a missing record stores nothing rather than raising an error. Look the group up by name at runtime, or hold the sys_id in a system property, so there is one value to correct per environment instead of a search through flow inputs.

Can you report on unassigned catalog tasks in ServiceNow?

Yes, and it is the single most useful report to build here. List sc_task records where state is one of 0 Pending, 1 Open or 2 Work In Progress and assignment_group is empty. Give that list a named owner and a schedule. Pending tasks with no group are invisible twice over, since they sit in nobody queue and are excluded from most open-backlog dashboards.

What is sc_task in ServiceNow?

sc_task is the database table behind catalog tasks, the SCTASK records created under a Requested Item to carry out service catalog fulfillment work. It extends the base task table and sits below sc_req_item in the request hierarchy. Business rules, assignment rules, SLAs and reports that need to describe real fulfillment activity are built against sc_task rather than the parent request records.

How do you create a catalog task in ServiceNow?

Attach a flow or a workflow to the catalog item, then add a task-creation step. In Flow Designer that is the Create Catalog Task action, where you set the short description, the assignment group and any variables the fulfiller needs. In the legacy workflow editor it is the catalog task activity. Tasks can also be created by script against sc_task, though the flow action is the maintainable route for new items.