ServiceNow Request Fulfillment Routing Software: Flow Designer vs Assignment Rules

If you are deciding how catalog work gets its owner in ServiceNow, you are choosing between setting the assignment group at creation time in Flow Designer and leaving the field empty so an assignment rule fills it. You cannot meaningfully do both on the same task, because an assignment rule only populates an empty assignment group and never overwrites one. That constraint is the whole decision. Everything else, including whether you eventually add a routing layer, follows from which side of it you pick.

This comes up when a service catalog gets past about thirty items. Early on, every item has one obvious fulfillment group and somebody hard-codes it. Later there are eighty items, four of them route by region, two route by which product the requester picked, and a growing pile of SCTASK records arrives every morning with an empty Assignment group field. At that point people start shopping for request fulfillment routing software, and the honest first question is whether the platform you already pay for can do it.

The four mechanisms, and what each one actually costs

There are only four places an assignment group can come from on a catalog task, plus the option of a routing layer beside the platform. They are not interchangeable.

The first row is the one that costs teams the most time, so it is worth stating flatly. The Fulfillment group field on a catalog item is stored as the group field on sc_cat_item, and out of the box nothing reads it. Setting it does not populate the assignment group on the Request, the Requested Item, or any catalog task underneath. It is metadata about the item until you write something that copies it, most commonly the one-line workflow run script current.assignment_group = current.cat_item.group; on sc_req_item. Plenty of catalogs have that field carefully filled in on every item and route nothing from it.

Flow Designer: set the group when the task is created

The Create Catalog Task action has an Assignment group input, and filling it is the most direct answer. The task inserts already owned, there is no window where it sits unassigned, and the logic lives next to the item it belongs to, which is where a catalog builder expects to find it.

Two failure modes are worth knowing before you commit to this everywhere.

The first is portability, and it is the reason for most of the tickets that read routing worked in dev and broke in prod. A group sys_id pasted into a flow input is instance-specific. Group records created by hand in each environment get different sys_ids, and a reference field pointing at a sys_id with no matching record does not throw an error. It stores nothing. 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. 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 rather than a search through flow inputs.

The second is subtler. Community troubleshooting has repeatedly identified the Template value type as a cause of assignment_group values that look correct in the flow execution context and never land on the record. If your flow shows the right group and the task shows an empty field, change the value type before you rewrite the logic. The workflow-era equivalent is whitespace on a scratchpad value, which is why the accepted fix in those threads is task.assignment_group = workflow.scratchpad.amsGroup.toString().trim(); rather than a direct assignment.

The real cost of the Flow Designer approach is not technical. It is that the routing policy ends up distributed across every catalog item, maintained by whoever built each one. Change how the network team is structured and you are editing flows one at a time, hoping you found them all.

Assignment rules: let the engine decide

Assignment rules live on sysrule_assignment, apply to the task table and everything extending it, and sc_task qualifies. The engine evaluates them from the lowest order number upward, applies the first rule whose conditions match, and stops there. Later matching rules do not run and do not stack.

The constraint that governs everything here: an assignment rule fills an empty assigned_to or assignment_group and will not overwrite an existing value. A default value on the field counts as an existing value, because at insert the field is no longer empty. So does anything the Create Catalog Task action set.

Follow that through and the fork has no middle. Flow sets a group, and every assignment rule you wrote for sc_task is skipped on that record, permanently and silently. Flow sets nothing, the task inserts empty, and the engine gets its turn. 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 writing another assignment rule for catalog tasks, list the items whose task-creation step sets a group. On those items the rule you are about to write can never fire, and no error will tell you. If you want the ordering detail, including where assignment rules sit relative to business rules in the save sequence, we walked through it in ServiceNow assignment rules execution order.

So which one should you pick?

A workable policy, and one that survives a catalog growing past a hundred items:

• Use Flow Designer when the group is a property of the item. A laptop request always goes to hardware provisioning. Set it in the action, look it up by name, move on.
• Leave the field empty and use assignment rules when the group depends on the record. Region, requested-for department, product, priority. This is what the rule table was built for, and the conditions travel between instances cleanly.
• Write it down and enforce it. The failure is never one item, it is fifty items built to two different conventions by six people over three years.
• Build the unassigned report either way. List sc_task where state is 0 Pending, 1 Open or 2 Work In Progress and assignment_group is empty, and give it a named owner. Pending tasks with no group are invisible twice over, since they sit in nobody's queue and are excluded from most open-backlog dashboards.

The mechanics of each mechanism, including the full request hierarchy and the catalog task state values, are laid out on our ServiceNow catalog task assignment page.

What neither option does

Both answers put a group on the task. Neither puts a person on it. That distinction is where most fulfillment backlogs actually live, because a group is a binary: you are in it or you are not. It cannot express that somebody is at capacity, on shift, half time, or in training on one product and not another. ServiceNow leaves the second half to the group queue and whoever clicks first, which works when tasks are interchangeable and gets expensive when they are not, since the fastest person to claim work is rarely the one with the most room for it.

There is a second gap that shows up in mature catalogs. A correctly routed task can still reach nobody, because assignment group membership does not roll up the hierarchy. Send work to a parent group and it is offered to that group's direct members, which on a well-designed hierarchy is often an empty set. The queue name looks right on every report.

And plenty of fulfillment work is not really a ServiceNow problem at all. The task record tracks the request, but the provisioning happens in an identity provider, a device management console, a finance system or a SaaS admin panel, and somebody has to connect the apps and APIs that do the actual work before any of it can be automated end to end. Routing decides who picks the task up. It does not shorten the task.

Where a routing layer fits

Assigner runs beside the ServiceNow you already have rather than replacing any of it. ServiceNow stays the system of record for the request, the catalog and the reporting. Assigner decides who inside the group actually gets the work, using true circular round robin, weighted rotation so a half-time engineer carries half the load by design, enforced workload limits, skill matching and live availability. Every assignment records the rule that fired, the candidates it considered and why, so changing how work reaches a team is a rule edit rather than eighty flow edits or a roster change. The same engine covers support tickets, sales leads and ops tasks, which is the part native catalog routing cannot reach at all. Pricing starts at $12 per user per month billed yearly ($15/mo billed monthly), and the AI assists while the rules stay yours.

The short version

• The Fulfillment group field on a catalog item routes nothing. It is sc_cat_item.group and nothing reads it out of the box.
• Assignment rules only fill an empty field. If the flow sets a group, or the field has a default value, the rule never fires and never says so.
• Pick per item, by whether the group is a property of the item or of the record, then write the convention down so it survives the next six builders.
• Look groups up by name, never by pasted sys_id, or routing that worked in development will empty itself in production.
• A group is not a person. Both native options stop at the queue, and the queue is where fulfillment work waits.