Troubleshooting ServiceNow Request Fulfilment and Service Catalog: A Practical Guide

Troubleshooting the Service Catalog starts from the request timeline: items not visible to requesters, requests not routing to approvers, requests stuck in approval, fulfilment tasks not assigned, and lookups not populating. Each section below pairs a symptom with the record and field to check, followed by inspection points, escalation guidance, preventive measures and a triage sequence for the administrator on duty.

Catalog Items Not Visible to Requesters

If a catalog item exists but users cannot see it in the catalog, first verify that the item is published. View the catalog item record and check the ‘Active’ field—it must be checked. If the item is active but still not visible, check the visibility rule. Catalog items can be restricted by role: a rule might limit the item to users with a specific role, or to users in a specific department.

Test visibility by logging in as a test user with different roles and checking whether the item appears. If an item is visible to some users but not others, the visibility rule may be filtering correctly but the rule definition may have an error. Check the filter condition in the visibility rule.

Requests Not Routing to Approvers

If a request is submitted but does not move to the approval step, check whether the catalog item has an approval rule configured. View the catalog item and look for an ‘Approval’ section. If no approval rule is set, requests will skip approval. If an approval rule exists but requests are not routing, check whether the approval group or user is correctly specified in the rule.

Common cause: the approval rule specifies a group or user by name, but the name has changed or the lookup is incorrect. Test by creating a request and checking the ‘Approvals’ table directly to see if an approval record was created. If no approval record exists, the approval rule did not trigger.

Requests Stuck in Approval

If requests are waiting for approval and the approver is not responding, check first whether the approver received the notification. Check the email server logs or notification history on the request record to confirm the approval notification was sent. If it was sent, the approver may not have access to the request or may have overlooked the notification.

Check whether the approver has the ‘approver’ role. If the approver role is missing, the user cannot approve requests. Manually add the role to the user’s record. Some organisations also configure request delegation: if an approver is unavailable, requests automatically route to a backup approver. Check whether delegation is configured and whether the backup approver is available.

Fulfillment Tasks Not Assigned

If a request is approved but fulfillment tasks are not created or assigned, check the fulfillment workflow. View the Request Fulfilment flow in the flow designer or workflow editor and verify that tasks are configured to be created when requests reach the fulfillment stage. If tasks should be assigned to a group or queue, verify that the group or queue exists and has members.

Another cause: the request may be awaiting input before fulfillment begins. Check the request record for a ‘Ready for Fulfillment’ status—if it is not in that status, the fulfillment task creation may be blocked by a condition in the workflow. Check the workflow condition to see what must be true before tasks are created.

Request Data Not Populating from Lookups

If a catalog form asks a requester to select an employee, and employee data (department, manager) should be automatically populated from the CMDB, but the data is not appearing, check the lookup configuration on the form field. The lookup script must query the correct table and map fields correctly. Test the lookup by selecting an employee and checking the populated fields.

If the lookup runs but returns no data, the query in the lookup may be too restrictive. For example, if the query filters by department and the requester is not in the department, the lookup will return no results. Broaden the query or adjust the filter condition.

Lookups and Inspection Points

• Catalog Item Record: Active field (should be checked), visibility rule (should define who can see the item), approval rule (if approval is required), fulfillment workflow
• Request Record: Status field (should progress from ‘Submitted’ to ‘Awaiting Approval’ to ‘In Progress’ to ‘Fulfilled’), assigned group or user, related approvals and fulfillment tasks
• Approval Table: Check whether approval records exist for requests that should have approvals; if none exist, the approval rule did not trigger
• Fulfillment Task Table: Check whether fulfillment tasks were created; if none exist, the workflow may not have triggered task creation
• Notification Table: Check whether approval notifications were sent; if not, the notification rule may be misconfigured

When to Escalate

If a catalog item is active and visibility rules look correct but the item is still not visible, the issue may be in the visibility query logic. If a request is stuck in approval and the approver’s role is correct, the issue may be a workflow condition that is not being met. If fulfillment tasks are not creating despite the workflow being active, there may be a system error preventing task creation. Document the specific request ID and escalate to the platform team with this information.

Preventive Measures

• Test new catalog items by submitting a request as a test user in each role that should be able to see the item
• Monitor approval queue daily; if requests accumulate waiting for approval, escalate to approvers
• Review fulfillment task creation logs weekly to catch workflow failures early
• Validate that approval and fulfillment groups exist and have active members

Start from the request timeline before opening the catalog item

When a requester says a request has gone wrong, the instinct is to open the catalog item and check its configuration. That is usually the slowest route. The request record already holds a timeline of what actually happened: each status change, each approval, each task creation and each notification. Read that timeline first. It tells you whether the problem happened before the request reached the platform, inside a workflow step, or after a person acted on it, and every one of those points to someone different who should act.

Only once the timeline shows where the request diverged from its expected path should you go into the item definition, the approval rule or the workflow. Changing configuration to match a symptom you have not located yet tends to create a second fault on top of the first.

Symptoms that look like one fault and are usually another

Duplicate and reopened requests

Duplicates are a frequent report, and they are easy to misdiagnose. Before changing anything, check whether the second submission came from the same session moments after the first. If it did, the fix belongs in the form behavior, such as disabling the submit control after the first click, rather than in the approval or fulfillment design. A genuine duplicate by a different person usually needs a rule that flags similar open requests to the same fulfiller, not an automatic cancellation of one of them.

Reopened requests are a separate problem. A request that is reopened after fulfillment may skip approval if the rule was written for first submission only. That is sometimes the intended behavior, but if it was not designed, the reopened request reaches a fulfiller without the authority check that the original had. Decide the rule and document it before the next reopening arrives.

Cancelled requests that keep moving

A cancelled request that still generates tasks, notifications or an approval reminder is usually a workflow that checks for the trigger but not for the state. The useful test is to cancel a request at each stage, from awaiting approval to partway through fulfillment, and record which downstream actions still fire. The stage at which the leakage starts shows which part of the workflow needs a state condition added.

A triage sequence for the admin on duty

1. Record the request number, the requester, the item and the time the problem was first reported. Without these the rest of the work cannot be verified.
2. Read the request timeline and note the first event that differs from the expected path.
3. Check whether that event is a user action, an automated step or an integration response. The owner of the fix depends on which one it is.
4. Reproduce the path in a non-production copy with a test identity, feeding in the variable values taken from the live request.
5. If the reproduction fails in the same way, change the smallest part of the configuration that explains the event, and record the change against the request number.
6. Confirm the fix with a new request, not by reopening the old one, and tell the requester what changed in plain terms.

When the portal and the platform disagree

Requesters work in the portal, while admins often investigate in the standard platform interface. The two can show different things. Client scripts that run in one interface may not run in the other, and a field hidden in the portal may still be populated on the record. Before concluding that a request has the wrong data, check the same record in both views. A mismatch that is only visible in one view is usually a presentation fault, while a mismatch in the record itself is a data fault that needs a deeper look.

Should the fix be made in production or in a copy?

Make a change in production only when the fault is affecting live requests and the fix is small and reversible. For anything that changes approval routing or fulfillment assignment, reproduce the fault in a copy first, since a wrong fix to a live approval rule can send requests to the wrong people while the change is being corrected.

How do I tell a configuration fault from a data fault?

A configuration fault repeats for every request that follows the same path. A data fault affects one record or one group of records, usually because a user, group or lookup value changed. Test the same item with a fresh request. If the new request behaves correctly, look at the data on the original record and at the group or user it depended on.

When should the requester be told what happened?

As soon as the cause is known and the requester’s request is affected, even if the fix is not yet complete. A short message that says what happened, what is being done and when the requester will hear next prevents the duplicate submissions that make the next investigation harder. For related reading on status messages, see the article on request status transparency.

Can the same process handle a rejected request that the requester disputes?

Treat a dispute as a question about the decision, not a fault in the platform. Check the approval record and the stated reason first. If the rejection was consistent with the approval rule, the dispute goes to the approver or to the exception route. If it was not, the rule is the fault. For related reading on rejections, see the rejection analysis article.

Teams that track these faults over time may find the same symptoms return after each release. The testing and acceptance checklist for request fulfillment is the place to catch them before they reach requesters, and the incident management troubleshooting guide covers the parallel work when a fault is an outage rather than a request problem.