ServiceNow Request Fulfilment and Service Catalog: Roles, Responsibilities and RACI

Request Fulfilment needs four roles with clear decision rights: a Catalog Manager who owns the structure and forms, fulfilment teams who do the work, Service Owners who set scope and prerequisites, and approvers for cost, compliance or cross-team requests. The sections below define each role, give a RACI table, set escalation paths, name the common ownership gaps, and show how to agree decision rights before the first catalog release.

Core Roles in Request Fulfilment

A Catalog Manager owns the service catalog structure, defines what services are available, sets up request forms and determines who can approve which requests. This role is typically held by an IT process owner or service delivery manager.

Request Fulfillment Teams own the actual work of processing and completing requests. This spans intake (logging and categorizing incoming requests), validation (confirming prerequisites are met), execution (performing the work), communication and closure.

Service Owners define the scope of their service, set requirements for approval and fulfillment, and own outcomes when requests complete. They may also set prerequisites: required approvals, authorizations or conditions that must be met before a request can be fulfilled.

Approvers grant authorization for requests that exceed certain cost or complexity thresholds, require compliance review, or affect multiple teams. Approval workflows often escalate to different levels based on business impact.

RACI Matrix for Request Fulfilment

A RACI table clarifies ownership across key decisions:

Escalation Paths and Decision Authority

Escalation occurs when a request does not progress within expected time, when a requestor disputes a denial or delay, or when fulfillment complexity exceeds the handling team’s authority. Clear escalation paths prevent requests from disappearing and reduce decision delay.

Typical escalation for a stalled request moves to the fulfillment team supervisor, then to the service owner or IT manager. For disputed or complex requests, escalation moves through the approval chain: first-level approver to service owner to IT director depending on the issue.

Document which requestor complaints warrant escalation, who has authority to make exceptions, and what circumstances trigger involving security, compliance or finance teams.

Common Ownership Gaps

Many organizations struggle with unclear ownership of the catalog itself: no single person is accountable for removing outdated services, combining duplicates or updating forms when processes change. Assign this work explicitly to a catalog manager role with defined review cycles.

Approval authority often remains unclear, leading to approvers who feel uncertain about their decision rights or stakeholders who do not know who to contact for approval. Document approval thresholds, escalation paths and the roles authorized to make exceptions.

Approval workflows should be defined clearly, including thresholds that trigger different levels of review. High-value requests or those affecting critical services typically require management approval. Expedited approval paths may be needed for emergency requests or critical business needs. Document exceptions and ensure visibility to leadership.

Exception Handling and Appeals

Request approvers will encounter situations where a request does not fit standard criteria. Define a process for requesting exceptions: who has authority to approve exceptions, what justification is required and how exceptions are documented for audit.

Some teams implement an appeal process for denied requests. If a request is denied and the requestor believes the decision was incorrect, they can appeal to a higher authority. Define appeal criteria and decision timelines to keep the process moving.

Approval workflows should account for time-based escalations. Requests that are pending approval for an extended period should escalate to the next level of management automatically. Set escalation timelines that match your organization, with shorter timelines for high-priority requests.

Deciding who may approve a catalog request, and who may not

Most role confusion in request fulfillment is a question of decision rights rather than job titles. A catalog item can have an owner, a set of approvers, a fulfillment group and a requester, and each of those four can sit with a different person. When they do not line up, a request stalls at the first point where nobody is sure the decision belongs to them. The catalog manager’s job is to write down, category by category, which holder decides each thing that can happen to a request.

The decision that causes the most trouble is approval. A single person who owns an item, approves its requests and then fulfils them has no independent check on whether the request was sensible. That is acceptable for a low-cost item such as a replacement keyboard. For anything that grants access, commits spend or touches personal data, it removes the one control the approval step exists to provide. Separate the approver from the fulfiller wherever cost or sensitivity justifies it, and record the reason in the item description so that the next catalog manager does not simplify the route away without knowing why it was built that way.

A decision rights table to agree before building workflows

Use the table below as a starting draft for a workshop. The last column matters most, because it names who must be kept out of each decision. That is where the audit questions come from later.

A workshop sequence for assigning decision rights

Run the workshop with the catalog manager, two or three service owners and one representative from the fulfillment teams. Keep the list of decisions short enough to finish in a single sitting, and leave the detailed grid for a follow-up.

1. List every category of catalog item and mark the ones that carry cost, grant access or hold personal data. Separation of approval matters most in those marked categories.
2. For each marked category, ask who would be held responsible if the request were wrong. That person usually belongs in the accountable column, whatever their title suggests.
3. Name an approver role and an approval group for each category rather than individuals. People leave the business; groups can be given new members without changing any rule.
4. Confirm that no name appears as both approver and fulfiller for the same category. Where one does, add a second approver or record the risk and the person who accepted it.
5. Write the exception route: who may grant an exception, how it is recorded and when it lapses.
6. Check the finished grid against what the platform can enforce through approval rules and group membership before any build starts. A grid that cannot be implemented this way will drift within a quarter.

Agree the review cadence for this grid in the same workshop. For the wider rules that keep it current, see the governance model for request fulfillment.

Where role models break once the configuration is live

A role model on paper and a role model in the platform are not the same thing, and the gap usually shows up in three places. The first is the item owner field. It records who maintains the item, but it does not by itself route approvals, so teams that assume the owner will be asked to approve find that nothing reaches them. The second is an approval rule that names a group whose membership has changed, so requests either go nowhere or land with someone who has left. The third is a fulfillment group with no active members, which accepts assignments without complaint until somebody looks at the queue.

Review these three fields after every reorganisation. A short quarterly check that lists items whose owner is inactive, approval rules pointing at empty groups and fulfillment groups without members will catch most of the drift before a requester notices it. Where approvals are delegated during absence, the same check should confirm that the delegate still holds the approver role.

Questions to settle before the first catalog release

Some decisions cannot be settled by the workshop alone and need a named person to decide before go-live. Who may add a new catalog item without review? What happens to a request that matches no published item? Who arbitrates when two service owners both claim the same request type? Write each answer down with the date it was agreed, because a decision nobody can locate is treated as no decision at all.

Can the owner of a catalog item also approve its requests?

For a low-risk item with one owner and no spend, it can be a reasonable shortcut. For items that grant access, commit budget or handle personal data, separate the two roles. If the team is too small for a second person, move the approval to the owner’s manager. That keeps the decision outside the team that benefits from a quick yes. For a wider view of how service owners share these duties, read the service owner operating model article.

What should happen when a named approver leaves the business?

The request should not be re-routed by whoever happens to notice it first. Where the platform supports delegation, name a backup approver in advance. Otherwise the catalog manager reassigns the approval, records the change and tells the requester which person now holds the decision. Pending approvals belonging to a leaver should be checked during offboarding, and the approval controls article sets out the wider controls around them.

Who decides when a request falls outside the catalog?

Someone must own that boundary. Usually it is the catalog manager, who either adds an item, points the requester to another route such as the change request and catalog management service, or declines the request with a stated reason. A request that is neither accepted nor declined tends to sit in a generic queue for weeks.

How many approval levels are too many?

Every extra level adds elapsed time and gives the requester another person to chase. Add a level only when the reviewer brings information the earlier approver lacks, such as finance knowing the remaining budget or security knowing the data classification. If two levels look at the same facts, one of them is redundant.

The request fulfillment and service catalog library covers the surrounding process.