ServiceNow Order Guide Explained

What an Order Guide Is

An Order Guide is a template of multiple related service catalog items grouped together for quick ordering. When a user selects an Order Guide from the catalog, they are asked questions once, and those answers populate forms for all the items in the group. This simplifies ordering when multiple related services are needed together. For example, a new employee might need an Order Guide that includes computer hardware, software licenses, email account setup, and office furniture. Instead of filling out four separate forms, the user fills out the Order Guide once, and four related requests are created.

Order Guides are distinct from a service portfolio, which is simply a list of services grouped by category. An Order Guide is a coordinated request that ensures all parts of a complex delivery are captured together. It is valuable when related services depend on each other or when they need the same information to be provisioned correctly.

Where Order Guides Live in the Platform

Order Guides are defined in the Service Catalog module under Service Catalog > Order Guide. Each Order Guide specifies which catalog items are included, what variables are collected from the user, and how variables from the Order Guide are mapped to the specific items. When a user selects the Order Guide, they go through a multi-step flow where they answer questions that apply to all items, then they see a summary of everything that will be ordered.

Order Guides can contain conditions. For example, if the user indicates they are a manager, they might see additional items like a budget code authorization tool. If the user selects a certain office location, only items applicable to that location are shown. This makes the guide flexible and reduces unnecessary items in the order.

A Worked Example

Imagine a new employee onboarding process. The Order Guide asks: name, employee ID, manager name, office location, and department. Based on these answers, the guide includes a laptop computer (possibly different models depending on department), office software licenses (depending on role), an IT access provisioning form (department-specific), a building access card request, office furniture (depending on location), and a desk phone (depending on office). The user answers the questions once, and six different requests are created with the correct information filled in automatically.

Another example: disaster recovery testing. The Order Guide asks which applications should be tested, which recovery point target you need, and which recovery time objective. Based on these answers, requests are created for data backup, failover testing, documentation validation, and team training. Each request includes the specific applications and targets the user specified.

When to Use Order Guides

Order Guides are valuable when multiple related items are frequently ordered together. They reduce the number of forms the user must fill out. They reduce the chance of missing one item from a set that should be ordered together. They standardize the information collected so it is consistent across all related requests.

Order Guides are less appropriate when the items are rarely ordered together, or when they are ordered in different combinations by different users. If most users ordering service A also order service B, use an Order Guide. If some users order only A and some order A, B, and C in different combinations, a simple catalog with clear descriptions is better than a guide.

Common Misconceptions

A common misconception is that an Order Guide enforces that items are ordered together. In reality, an Order Guide is a convenience for common combinations. A user can still order items individually from the catalog. The Order Guide simply makes it easier to order the complete set. If you truly require certain items to always be ordered together, use a business rule that prevents ordering one without the other, rather than relying on an Order Guide.

Another misconception is that Order Guides are invisible to fulfillment. In reality, each item in an Order Guide creates a separate request. Fulfillment teams must fulfill each request independently. If items are truly dependent and must be fulfilled as a unit, an Order Guide is not the right approach. Instead, create a single request that encompasses all the work.

Design and Maintenance

Design an Order Guide based on how users think about work, not on your internal organizational structure. If users think of new-employee-onboarding as one big process, create an Order Guide for that, even if fulfillment involves three different departments. If users think of office relocation as a different set of services, use a separate Order Guide. Consistent naming and clear descriptions help users find the right guide.

Maintain the guide over time. As new items are added to the catalog, decide whether they belong in existing Order Guides or if a new guide is needed. Remove items from guides if they are no longer relevant. Test guides periodically to ensure the variable mapping is working correctly and that users get the correct items.

Deciding whether a bundle belongs in an order guide before anyone builds it

Many order guides fail at the design stage rather than during the build. A catalog owner gathers the items a department tends to ask for, places them in one guide, and only later finds that half of them are requested alone, that two of them need different approvers, or that the questions the guide asks never reach the items below it. The first useful step is to pull request history and count how often the candidate items arrive together within the same short window. If that overlap is thin, the work belongs in a clearly categorized catalog, because a guide adds a screen the requester must pass through and gives nothing back.

Choosing the right container for the bundle

An order guide is one of several ways to group requests, alongside the catalog item and the variable set. The table below sets out where each option tends to fit, so the decision is made on the request pattern rather than on preference for a feature.

Request pattern	Better fit	Reason
The same set of items is requested together nearly every time	Order guide	One set of answers feeds every child request, so the requester answers once
Items share several questions but are requested in changing combinations	Catalog items that read a shared variable set	Each requester picks what they need and still answers the shared questions only once per cart
One piece of work with a single approval and a single fulfillment group	Single catalog item or record producer	A guide would split one piece of work into several tasks that each need closing
Items that must be delivered or rolled back as a unit	One request with its own fulfillment workflow	Child requests are fulfilled independently, so a partial delivery is possible

Building the guide in an order that avoids rework

Teams that build guides from the screen outward often end up rewriting the variables twice. Starting from the data avoids that. The steps below each depend only on the step before, which matters once a guide grows past a handful of children.

1. Write the full list of questions the guide will ask, one line per question, and beside each line note which child item consumes the answer.
2. Delete any question that no child item uses. Questions that feel useful but feed nothing become friction at the summary step.
3. Confirm that every child catalog item and its variables exist and are in their final names. A mapping built against a name that later changes will fail silently in some branches only.
4. Map each guide variable to its child variable. Mark the mappings that rely on a default value or a script, because those are the first to break after an upgrade or a rename.
5. Add conditions last, one at a time, and test each branch with its own requester profile before adding the next condition.
6. Run a small pilot with a handful of requesters from different departments before publishing, and read the child requests they produce rather than the confirmation screen alone.

What usually goes wrong once a guide is live

A common post-launch fault is a mapping that stops working because someone renamed a child variable for tidiness. The guide still publishes, the summary still looks correct, and the child request arrives with an empty field. A second fault is the conditional item that is hidden from the requester but still expected by the fulfillment team, who then chase a request that was never created. A third is cancellation: when a requester removes one child from a guide, the others remain, and fulfillment staff may not realise the set is now incomplete. A guide also inherits whatever stale items sit in the product catalog, so review those first. Each of these is a process gap as much as a configuration gap, so the owner of the guide should own a short list of the child items and their variable names and review it whenever a child changes.

A checklist for the first month of running a guide

• Confirm the guide’s owner and the owner of each child item, and record both in the item descriptions.
• Sample a set of completed guides and compare the child requests against the answers given. Look for empty fields and unexpected items.
• Check the cancellation path by removing one child from a test guide and confirming the fulfillment team sees the change.
• Review the requester feedback route and make sure it reaches the guide owner, not a general mailbox.
• Agree a date for the first revision, based on how often the child items themselves change.

Telling whether the guide is doing its job

Judge a guide by what happens after the summary step. A high rate of requesters abandoning the guide at the summary usually points to questions that feel irrelevant or to a summary that hides what will be created. A rising number of child requests canceled soon after creation suggests that a condition is showing items people did not expect. Requests returned by fulfillment for missing information are a useful signal too, because they tell you which shared questions are too loosely worded. None of these measures needs a target value on day one. Agree the level at which a reading prompts a conversation with the service owner, and review that level after the first full cycle of requests.

When not to build an order guide

Do not build a guide to force a combination that the business does not actually want. If a department says the items belong together but their request history shows them ordered separately, a guide will create requests nobody asked for. Do not build one to hide a broken catalog item either; fix the item first, because a guide will inherit every fault in its children. And do not use a guide where the real need is approval routing, or where a single submission is the whole task, in which case a record producer is simpler. Approvals attached to child items still arrive as separate tasks, so a guide will not consolidate them.

How many items should one guide contain?

There is no fixed ceiling, but a guide with many children becomes hard to test and hard to explain to requesters. When a guide reaches the point where its branches can no longer be tested in one sitting, split it along the line that the requesters themselves use, such as role or site, rather than along the line that fulfillment uses.

Who should own a guide that spans several fulfillment groups?

Name one business owner for the guide as a whole, separate from the fulfillment owners of each child. That person decides which questions the guide asks and which children stay in it. The fulfillment owners decide how their own child is delivered. Confusion arises when no one holds the first role and each child owner edits the guide to suit their own queue.

Can a guide be copied to another site or department?

Copying is quick, but the copy inherits the same child items, which may carry local assumptions such as a site-specific supplier or a cost center. Review every child and every condition in the copy before publishing it, and keep a note of which items were changed for the new audience.

What should happen when a child item is retired?

Remove it from the guide first, test the remaining branches, and only then retire the item. Retiring the item first leaves the guide pointing at something that no longer exists, and the failure is visible only to the requesters who choose that path.