OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow request and catalog practice

ServiceNow change, request and service catalog management with clear routes

ServiceNow change, request and service catalog management should help a person recognise the service or change they need, provide information the fulfilment team can use and understand what happens after submission.

Discuss ServiceNow request and catalogue management

Start with tasks users recognise

People may want access, equipment, a change, a report or help with a service. They may not know the internal team name, application owner or technical category. Catalogue structure should reflect the task while preserving internal routing behind the experience. If two items appear similar, explain the difference before selection.

Give each catalogue item a clear promise

An item should explain what can be requested, who it is for, what information is needed and what the requester will receive. The outcome should be honest. Do not promise a result the fulfilment process cannot consistently provide. A shorter catalogue is not automatically clearer if its remaining items have vague boundaries.

Keep questions connected to fulfilment and approval

Ask for information that affects eligibility, approval, routing, fulfilment, security, communication or reporting. Conditional questions can keep the first view simple while gathering detail when relevant. Review every field with the person who fulfils the work; unused questions add friction without improving the outcome.

Build ownership into the request path

Each item needs a process owner, fulfilment owner, approval rule, knowledge owner and review point. Define what happens when the item no longer fits, the owner changes, approval is delayed or a request becomes an incident. The platform team may maintain configuration while a service or fulfilment owner remains accountable for the promise.

Review items through request evidence

Look at abandoned requests, repeated searches, reassignments, returned forms, cancellations and reopened work. Each pattern can indicate confusing language, too many questions, missing ownership, an incorrect approval or a fulfilment result that does not match the item promise. Improve the item before creating another similar route.

For operating context, see ServiceNow ITSM and Service Operations. For workflow boundaries, review ServiceNow Workflow Data and Context Design.

Discuss ServiceNow request and catalogue management

Bring one request item, approval path or change route that creates unclear choices, repeated clarification or uncertain fulfilment. OBLYTECH can help connect the user task to the workflow, owner and closure evidence.

Start the conversation

The question a catalog has to answer before anyone opens it

A service catalog is a set of promises. Each item tells a person what they can ask for, what they will need to supply and what will happen next. When a catalog grows by adding items for every request that arrived once, the promises start to conflict. Two items cover almost the same need, one implies approval and the other does not, and the requester has to guess which route fits. The redesign question is therefore not how many items to keep. It is whether each route is clear enough that a person can choose it without asking someone first.

This page is for service owners, catalog managers and fulfillment leads who are deciding whether to consolidate, rename or rebuild the request routes in ServiceNow. It assumes the platform is already in use and that the team wants the front of the process to reflect the work people actually bring. It does not cover the design of the underlying workflow data, which is treated separately in the workflow data and context design route.

Deciding which request type a need belongs to

Requests, incidents, standard changes and knowledge questions are routed differently, and the catalog is only one of them. Confusion starts when a person submits a request for something that is actually broken, or raises an incident for something they simply want. Fixing that confusion starts with a short routing test that a catalog owner can apply to any proposed item.

Need the person describesBetter routeOwnership testCommon misuse
Access, equipment or a standard serviceCatalog request itemIs there a named fulfillment owner and a repeatable result?Used for one-off projects with no defined result
Something that has stopped workingIncidentIs service degraded for someone now?Logged as a request so it waits in a queue
A change to a shared systemStandard or normal changeDoes the change affect a shared configuration or control?Submitted as a request to avoid the change path
A question with a known answerKnowledge articleCan the answer be written once and kept current?Turned into a catalog item that nobody fulfils

When a standard change should become a catalog item

A change that repeats in the same form, with the same approvals and the same evidence, is a candidate for a catalog item backed by a pre-approved standard change. The item carries the decision that has already been made, and the requester supplies only the variables that differ. That pattern works well for things like adding a user to a known group or extending a certificate within a defined window. It does not work for changes whose risk varies with context, because a pre-approved route then hides the variation the approver should see.

Naming and grouping items so requesters can choose

Names are often where catalogs lose people. An item called Application Access Change tells a requester nothing about whether it is for them, what it grants or how long it takes. An item called Request access to the finance reporting view, with a supporting sentence about who it is for, lets the person decide in seconds. Naming should describe the task in the requester’s words and keep internal team names out of the title, which can stay in the routing behind the item.

Grouping follows the same logic. Groups should reflect situations a person is in, not the departments that fulfill the work. A new starter, a person changing role and a manager planning a team move each have a different set of needs, even when several items are shared between them. A useful test is to ask whether a requester could find the right item without knowing the team that delivers it. If the answer is no, the grouping is still organized around the platform.

  • Give every item a title a requester would use, and a sentence that says who the item is for.
  • Explain the difference between two similar items at the point of choice, not in a separate document.
  • Keep internal routing, assignment groups and approver identities out of the requester’s view.

Designing variables and approvals as one decision

Each variable on an item is a question, and each question costs the requester time. The right set is the smallest group that changes eligibility, approval, routing, fulfillment, security or the status update the requester receives. Questions that exist because someone once wanted a report are the first to go. Conditional questions help: a first view can stay short, and the form asks for detail only when the answer makes that detail necessary.

Approvals must be designed alongside the variables, because a variable often determines who approves. If the approval rule depends on a cost center, a data classification or a system owner, that information should be captured before the approval step, not requested again afterwards. A common failure is an item that collects everything, then sends the request to a manager who cannot see the field that determines whether the manager is the right approver at all.

Testing whether each item keeps its promise

An item’s promise is tested by fulfillment, not by the requester who submitted it. The practical check is to read a sample of completed requests against the sentence the item makes. Did the requester receive what the item said they could ask for? Did the fulfillment team need information that the form did not collect? Did the request come back for clarification, was it reassigned, or did it become an incident later? Each of those patterns points to a specific fix, usually in the wording, the variables or the owner.

Abandoned submissions and canceled requests are the quieter signal. An item that people start and leave is often asking for something they cannot provide at the point they are asked. Reviewing where people stopped is usually more useful than counting how many finished, because the stopping point shows which question the requester could not answer.

Retiring and merging items without breaking open work

Merging overlapping items is often a useful cleanup, and it is easy to do badly. Requests already open against the retired item still need an owner and a path to closure. The safe sequence is to publish the replacement, route new requests to it, leave the old item visible with a clear pointer for a defined period, and then close the old item only once no open work depends on it. Deleting an item that still has open requests leaves those requests orphaned, and nobody notices until a requester asks where their request has gone.

How the catalog sits within the wider service operations model

A request catalog is one part of the service operations model. Its promises depend on incident handling, knowledge quality and the platform’s data model. When a catalog item keeps failing, the cause is often outside the item, such as an approval group that no longer exists or a knowledge article that has gone out of date. The ITSM and service operations page looks at how work moves through incident, request, problem, change and knowledge processes, and the item redesign should be planned with that operating view in mind rather than in isolation.

Common questions about catalog redesign

How many items should a catalog have?

There is no correct count. A catalog is working when each item is distinct, owned and fulfilled, and when a requester can find the right one quickly. A catalog that shrank by merging items with vague boundaries has not become clearer, and a catalog with many well-defined items may be exactly right for the work it covers.

Who should own a catalog item?

Two owners are useful. A process owner is accountable for the promise the item makes to the requester. A fulfillment owner is accountable for delivering it. The platform team maintains the configuration, but the promise belongs to the people who keep it.

Should we use the catalog for employee questions as well?

Some employee questions are better answered by knowledge than by a request, and the knowledge and self-service optimization page deals with connecting real questions to clear articles. If a question has one correct answer that does not change with the person, a knowledge article is usually the right route, and a catalog item should be reserved for actions that someone must carry out.

If your catalog has items that people struggle to choose between, or requests that come back for clarification every week, take one request item and its last few completed cases and test them against the questions above, starting with the item’s name, its variables and its owner.

ServiceNow guides on this topic

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

Related guides

More in this section