Troubleshooting ServiceNow Demand Management: A Practical Guide

This page helps whoever supports Demand Management work out whether a stalled or misrouted request is a data, workflow, notification or governance problem, which place to check first, and when a fix should wait before any configuration is changed.

Recognizing Demand Management failures

Demand Management problems surface as requests disappearing into a black hole, stalling in approval queues, or being routed to the wrong team. When business units complain that requests are taking too long to review, or requests are being rejected without explanation, the Demand workflow is broken. Whoever investigates these issues should look at request state transitions, assignment ownership, and workflow logic. If requests consistently spend longer than expected in Assessment status without moving to Approved or Rejected, the workflow is blocked. If requests with unclear priority scores are approved or rejected inconsistently, the assessment criteria need clarification.

Request submission and classification issues

Demand requests start in a submission portal. End users may submit requests that are incomplete or misclassified. A request submitted without business justification cannot be assessed fairly. A request for infrastructure that is classified as a data analytics request will be routed to the wrong team. Query the Demand table to see whether incoming requests have required fields filled: description, business justification, requested start date, business impact. If many requests lack these fields, the submission form is not enforcing requirements. Update the form to make fields mandatory. If requests are frequently misclassified—submitted as one type but need to be reclassified by the Demand Coordinator—add form help text that explains how to choose the correct category, or provide examples of each category type.

Assessment and scoring delays

After submission, a Demand Coordinator must assess the request and assign it a priority score. If assessment takes longer than your target turnaround, it delays the prioritization process. Identify whether assessment is blocked because coordinators lack information or because the assessment process itself is complex. If the form lacks business justification, coordinators cannot assess value and must request more information—this causes delay. Streamline the submission form to capture information coordinators need. If assessment is complex because many factors must be considered and multiple stakeholders must provide input, document the assessment process clearly and train coordinators on how to apply it consistently.

Assessment may also stall if coordinators are overloaded. If coordinator workload exceeds capacity, requests accumulate in a queue. Monitor the number of requests waiting for assessment. If the queue is growing, it signals capacity problems. Add assessment capacity or streamline the assessment process.

Routing and ownership problems

After assessment, requests are routed to the appropriate team or owner. An infrastructure request goes to Platform Operations. An application request goes to Application Development. If requests are frequently misrouted—ending up with the wrong team—the routing rules need adjustment. Review the routing configuration: each request type should be routed based on clear criteria. A request for database server provisioning should be routed to the Database team, not the Network team. A request for an analytics dashboard should be routed to Analytics, not Infrastructure. When routing failures occur, check whether the request type was misclassified (it came in as the wrong type) or whether the routing rule itself is wrong (the rule points to the wrong team).

Approval workflow and decision delays

After routing, an owner must approve or deny the request. If requests stall in Pending Approval status for longer than your target turnaround, approvers are either overloaded, unclear on criteria, or not receiving notifications. Check whether approvers are receiving notification emails when requests arrive. If notifications are not being sent, fix the workflow notification configuration. If approvers are not responding to notifications, escalate to their management. If approval criteria are unclear—approvers cannot decide whether to approve without more information—document approval criteria clearly. Create a rubric: requests that meet criteria A, B, and C are approved; requests that fail any criterion are rejected. Train approvers on how to apply the rubric consistently.

Status transparency and stakeholder communication

Business units submitting requests need visibility into status. If a request is pending approval and has been for three weeks, the business unit should know why. Is the approver unavailable? Is more information needed? Is the request being reconsidered? Without this visibility, business units assume the request is lost and start escalating. Ensure the request status and status comments are visible on the portal. When a request is held pending additional information, add a comment explaining what information is needed and when the business unit can expect a decision. Proactive communication reduces escalations.

Integration with portfolio planning

Demand Management should feed into IT portfolio planning. Requests that are approved should be tracked against planned capacity. If demand consistently exceeds available capacity, portfolio planning must either reduce demand or increase capacity. The issue is often that demand approval is decoupled from capacity checking. A request is approved in Demand Management but is not scheduled into Resource Management because resources are not actually available. This creates false commitments. Integrate Demand Management with Resource Management so requests are only approved if resources are available to execute them. If resources are not available, the request is queued or conditional on resource availability.

Start with the record’s activity trail before touching configuration

When a demand misbehaves, the usual response is to open the workflow and start editing. That often makes the problem harder to diagnose, because the next person cannot tell which change fixed what. The better first move is to open one affected record and read its activity trail from the first submission to the current state. Each entry tells you who or what changed a field, when it changed, and which automation caused it. Many demand problems fall into four families visible in that trail: the data was wrong when it arrived, the record moved through the wrong path, the right person was not told or could not act, or a decision was made outside the tool and never recorded in it. Naming the family first narrows the search to one of four places instead of the whole configuration.

Mapping each symptom to its likeliest source

A triage order for a problem nobody has explained yet

1. Reproduce the problem on one record, and note the exact user role and time at which it appears.
2. Read the activity trail for that record and write down every automated change, not only the human ones.
3. Check whether the same problem appears on records created before and after the last change to the workflow. A change in behavior at a fixed date points to configuration, while a gradual pattern points to people or process.
4. Test the same action with a sample account that holds only the role the reporting user holds, so that access problems are not mistaken for logic errors.
5. Decide whether the fix belongs in the form, the workflow, the notification set or the governance routine, and make the change in only one of those places.
6. Re-run the reproduction on a fresh record and confirm the trail shows the expected sequence.

Why reports and portal views disagree

A common source of distrust is a dashboard total that differs from what a requester sees in the portal. The two views usually use different filters. The report might count every record with an open state, while the portal hides records the requester does not own or that were moved to a parent item. Neither view is wrong in isolation, but a board that reads both will assume one of them is broken. Agree on the definition of an active demand before building the first dashboard, and label each view with the definition it uses so the difference becomes a known fact rather than a dispute.

When a fix should wait

Not every anomaly justifies a change. If a demand was approved outside the process by an executive and the record simply lacks the decision, the correct fix is a governance conversation and a corrected record, not a new automation that tries to infer approvals. Similarly, if a notification fails only for one distribution list that is known to be retired, the right step is to update the list membership, not to rewrite the notification logic. Hasty automation tends to introduce a second problem that is harder to trace than the first.

Why would a demand look correct in the portal but fail a report filter?

The portal often shows the display value of a choice field, while the report filters on the underlying stored value. A label that was renamed without updating the stored value will look identical to users and still drop out of the filter. Compare the stored value on the record with the choice list before assuming the report is broken.

Should we turn on verbose logging to find the cause?

Detailed logging is useful for a short, defined investigation and expensive to leave running. Enable it for the affected workflow only, capture the entries for a few reproductions, and switch it off once the cause is identified. Keep the captured output with the investigation note so that the same question can be answered later without repeating the work.

What do we do when two teams disagree about who should own a stuck item?

Do not reassign the record to settle the argument. Check the routing rule that produced the assignment, then decide which team owns that category of work and change the rule if needed. Reassigning one record only moves the disagreement to the next similar item.

Is it safe to fix a bad record by editing it directly?

Editing the record is acceptable when the correction is factual and documented, such as restoring a requester name. Editing a state or a score to make a report look right is not acceptable, because the activity trail will then describe a decision nobody made. Record the correction in the comments with the reason and the person who approved it.

Next step

If a demand problem keeps returning after each fix, the recurring cause is often in governance or access rather than in the form. The access design guide for demand management covers the role model in more depth, and the SPM managed support service page covers ongoing issues after go-live.