OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Catalogue Requests: Define Eligibility Well

ServiceNow catalogue requests should tell the requester what is provided, who can request it, what conditions apply, what approval is needed, and what fulfilment will do. Eligibility rules reduce avoidable rework when they are understandable before submission and enforced consistently afterward.

For service-catalogue owners deciding whether request choices are clear, eligible, and ready for fulfilment..

ServiceNow catalogue requestsrequest eligibilitycatalogue item design
Discuss this ServiceNow topic

Guide map

Deciding who can order each catalog item

Explain what the request provides

A catalog item should state what the requester receives, what it excludes, and how long fulfillment normally takes in plain words.

State who can request and under which conditions

Write eligibility as plain conditions, such as role, location, or department, so a requester can tell before submitting whether the item applies.

Match eligibility to approval and fulfilment

Check that every eligibility rule maps to an approver and a fulfilment group, so a request that passes the form does not stall afterward.

The practical framework

Define ServiceNow catalogue-request eligibility with requester, service, location, access, approval, fulfilment, exception, evidence, and closure rules.

Explain what the request provides

Describe the outcome, scope, included work, exclusions, expected evidence, and handoff. A request choice should not promise an outcome that the fulfilment group cannot control. Make the boundary visible before the user selects it.

The ServiceNow service-catalogue route is the relevant internal destination for catalogue design and user guidance.

State who can request and under which conditions

Define requester, beneficiary, service, location, role, data, access, timing, and prerequisite conditions. Use language the requester understands and avoid forcing them to guess which internal category applies.

The ServiceNow access-controls route provides an internal path when eligibility affects access or control evidence.

Match eligibility to approval and fulfilment

Connect the eligibility decision to the approver, task, data needed, fulfilment group, validation, and closure condition. If eligibility changes after submission, record why the request was re-routed or declined.

The ServiceNow request-approval route is relevant when eligibility leads to an approval decision.

Handle exceptions without breaking the rule

Define who can approve an exception, what evidence is required, what risk is accepted, and when the exception expires. An exception should not silently become a new permanent route without a decision to change the catalogue item.

The ServiceNow continuous-improvement route supports review of recurring exceptions.

Review unsuccessful or misrouted requests

Examine rejected, cancelled, returned, duplicate, and misrouted requests. Classify the cause as unclear content, wrong eligibility, access, approval, fulfilment, data, or user understanding. Change the catalogue or process only when the evidence supports it.

The ServiceNow request-fulfilment route gives an internal path for workflow review.

Common questions

Questions teams ask about catalogue eligibility

Should eligibility be enforced in the form?

Where practical, the form should prevent choices that are clearly invalid and explain why. Some decisions require later evidence or approval, so the form should not pretend to determine what it cannot know.

What should happen when a requester is not eligible?

Explain the reason, preserve the request context, identify an alternative route when one exists, and record who decided. Do not silently close the request without helping the requester understand the next step.

The research-grounded boundary

The research does not treat Now Assist and AI Agents as an isolated feature. It appears within ai and agentic ai discussions where data, permissions, workflow context, and human decisions meet. That is the useful lens for ServiceNow catalogue requests: define what the platform may do and what a person must still confirm. The catalog request eligibility decision should therefore be traceable from its starting condition to its owner, exception, evidence, and next review.

Decide where eligibility is enforced before writing any rule

A catalog item that anyone can see and order can eventually be ordered by someone it was never meant for. The decision for the catalog owner is not whether to check eligibility, but where the check lives: in the visibility of the item, in the form the requester completes, in a script that runs on submit, or in the approval that follows. Each location catches a different mistake and leaks in a different way. Teams that pick one location and assume it covers everything usually discover the gap when a fulfilment group receives a request for a software image on behalf of someone who was never entitled to it.

Where each control stops working

Control pointWhat it does wellHow it leaks
Access rules on the catalog itemHides the item from people who do not qualifyHiding is not blocking. Routes that bypass the portal view, such as integrations or imports, can still create the request
Variables and UI policies on the formGuides the requester and removes impossible choicesRuns only in the browser, so requests created through integrations or imports skip it
Client or server scripts on submitRejects ineligible requests before they enter the queueLogic copied into several scripts drifts apart over time
Approval rulesPuts a person in the loop for judgment casesApprovers approve on trust when the request looks routine

The practical answer is layered. Visibility keeps the choice clean for most people, and the UI policy logic on the form handles the guidance. A server-side check protects the rule itself, so an ineligible request cannot be created by any route. Approvals are kept for cases where eligibility depends on a judgment a script cannot make, such as a business justification for an exceptional software license. Catalog design more broadly is the subject of the catalog design guide.

Eligibility inputs that are worth the effort

The inputs that matter are usually already in the platform: group membership, location, employment type, manager, cost center, and whether a prerequisite item has already been fulfilled. Build the check on fields maintained by a source of truth. A rule that reads a free-text department name will fail the first time a team is renamed. If an input is unreliable, the rule should say so and send the request to a person rather than guess.

A build sequence that stays testable

  1. Write the eligibility statement in plain language for each catalog item, naming the requester, the condition and the reason for the condition. If the reason cannot be stated, the rule is probably a habit rather than a control.
  2. List the data source for each condition and confirm it is current for the whole population, including contractors, leavers and people on secondment.
  3. Put the server-side check in one place, such as a shared script include that each item calls, so the same logic runs whichever route creates the request.
  4. Define the message an ineligible requester sees. It should name the reason in plain words and give the next route, such as a manager or a different item.
  5. Test with an ineligible user through each route: the portal, a direct link, an integration and a record producer that copies data from a case.
  6. Confirm that approvers can see the eligibility result on the request, so the approval is a decision rather than a rubber stamp.

Signs the rule is doing its job

Look for ineligible requests that stop reaching the fulfilment queue, and for rejected requests that carry a reason the requester understood. A drop in orders after an eligibility change is not automatically a failure, because the rule may have stopped people ordering things they were never going to receive. A rise in requests returned by fulfilment teams for eligibility reasons usually means the check is reading the wrong data.

When not to encode eligibility in the platform

Do not script a rule that depends on a decision nobody has written down. If two managers would decide the same case differently, the platform will hard-code one answer and hide the disagreement. Settle the policy first, then encode it. For organizations that route changes and requests through one catalog, the ServiceNow change, request and service catalog management page covers that area. Also avoid building an elaborate eligibility matrix for an item requested only a few times a year. A simple approval with a clear note may serve better and cost less to maintain.

Eligibility questions that come up after launch

Should a hidden catalog item still be protected on the server?

Yes. Treat hiding as a usability measure and blocking as the control. Any item whose order would create cost, access or a fulfilment obligation needs a check that runs when the request is saved.

How do we handle a requester whose eligibility changes after they submit?

Decide whether eligibility is checked once at submission or again at fulfilment. For access and licenses it is usually both, because the person may have left between the two events. Write the rule into the item description so the fulfiller knows what to confirm.

Who owns the eligibility rule when it fails?

The catalog owner owns the rule and the service owner owns the policy behind it. When a failure traces back to bad source data, the data owner corrects the data, and the catalog owner confirms the check now reads the corrected field.

Can one rule serve several catalog items?

It can, and it should where the policy is the same. Reuse the check through one shared component, but keep item-specific reasons separate so the message the requester sees still names the right product.

Next step for catalog eligibility

If your catalog has items being ordered by the wrong people, a short review of where each control sits is often the fastest way forward, starting from one example item and its current rules. Questions can be sent through the contact page.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading