Bundling Multiple Items into a Single Request (Order Guides)

In the Service Catalog, users typically request one "Catalog Item (sc_cat_item)" at a time. However, there are cases where you want to request multiple items at once, such as an "Initial Setup for New Hires," which might include a laptop, monitor, email account, and VPN access. The mechanism that allows these to be requested together is the Order Guide.

In this article, I verified the internal table structure of ServiceNow Order Guides using a live PDI (Personal Developer Instance). There are two main components: the fact that the Order Guide itself is a "special catalog item" (inheriting from sc_cat_item), and the "Rule" table, which dynamically determines which items to include based on the answers to the initial questions.

The intended audience is administrators and developers who have experience with ServiceNow Incidents and understand that a "Catalog Item = one unit of request" in the Service Catalog. This article is for those who want to understand the structure of Order Guides that allow multiple items to be requested at once.

What you will learn in this article

• That an Order Guide (sc_cat_item_guide) is a "special item" that inherits from a Catalog Item (sc_cat_item)

• That items to be included in the guide are held in a separate table, sc_cat_item_guide_items (label "Rule"), as "included items + conditional logic"

• That the included items change dynamically based on the values of guide variables answered on the first screen (Describe Needs). In the live environment, I confirmed the condition where the Developer Laptop is included when laptop_type=developer

• The roles of guide-specific fields (two_step / cascade / include_items, etc.)

• That there are two OOTB Order Guides (New Hire / Request Developer Project Equipment)

• A list of URLs to check when verifying in a live environment

What is an Order Guide: Bundling multiple items into a single request

An Order Guide is a mechanism for requesting multiple catalog items in a single Request. Users first answer several questions on the "Describe Needs" screen, and based on those answers, the necessary items are selected and requested together.

Below is the screen for the "New Hire" Order Guide opened in the live Service Portal. At the top, there is a 3-step flow: Describe Needs -> Choose Options -> Summary. Items necessary for a new hire, such as an email account, laptop, and monitor, are bundled into a single request. This screen represents the visible side of sc_cat_item_guide and its rules.

You can check this guide screen at the following URL (please replace <YourInstance> at the beginning with your own instance).

https://<YourInstance>/sp?id=sc_cat_item_guide&sys_id=<ガイドのsys_id>

The overall picture is illustrated as follows. The user's answers (guide variables) are evaluated against rule conditions to determine which items are included.

In the PDI (Zurich / OOTB) I checked this time, the counts were as follows.

• Order Guide (sc_cat_item_guide)... 2 items (New Hire / Request Developer Project Equipment)

• Guide rules (sc_cat_item_guide_items)... 20 items(Total of 2 guides. Of which 18 are conditional / 2 are unconditional)

There are only 2 order guides OOTB. Compared to the 196 catalog items, the guides were configured as entry points for a very small number of "bundled requests."

An order guide is a "special catalog item" (inherits from sc_cat_item)

An order guide (sc_cat_item_guide) is not an independent, separate entity, but rather a "special item" that inherits from catalog item (sc_cat_item). It inherits the basic fields of an item such as name, category, sc_catalogs, picture, and short_description as they are. It is structured by adding just a few guide-specific fields on top of that.

I have summarized the inheritance relationships and counts of the PDI (Zurich / OOTB) I checked this time in a table.

There are two key points to grasp. One is that sc_cat_item_guide inherits from sc_cat_item. The other is that the actual items included in the guide are in a separate table called sc_cat_item_guide_items (label "Rule"). Thanks to the former, guides can also be lined up as "request buttons" on the catalog screen and belong to categories or catalogs. The latter is an independent table that inherits from Application File, and it is a "rule row" that holds references to a guide (→sc_cat_item_guide) and an item (→sc_cat_item). Incidentally, the parent sc_cat_item itself also inherits from Application File (sys_metadata) and had 76 unique fields.

The actual form for the guide itself is as follows. Items such as Name, Catalogs (Service Catalog), Category, Two step, and Cascade Variables are listed. You can see that guide-specific settings are placed on top of the same framework as a regular catalog item.

You can check the list of guide bodies from the following URL.

https://<YourInstance>/sc_cat_item_guide_list.do

Guide-specific fields: two_step / cascade / include_items

There were only 7 unique fields (including sys_id) that the order guide adds to sc_cat_item. The content of the guide consists of a few switches that determine how requests are bundled.

The main ones are described as follows.

• two_step (Two step) ... When turned on, it becomes a two-stage process of "Describe needs → Select options." Both of the 2 guides in this PDI were false.

• cascade (Cascade Variables) ... When turned on, the values of variables answered on the first screen of the guide are automatically passed on to variables with the same name in each included item. Both of the 2 guides in this PDI were false.

• include_items (Show Include Toggle) ... Displays an "Include/Exclude" toggle for each item (default true).

• order_to_cart (Order to cart) ... Whether to add directly to the cart (default false).

Fields such as name, category, and the associated catalog (sc_catalogs) are not unique to the guide, but are inherited from the parent sc_cat_item. Therefore, guides can also be categorized and displayed on the catalog screen just like regular items.

The definition of guide-specific fields can be confirmed at the following URL.

https://<YourInstance>/sys_dictionary_list.do?sysparm_query=name=sc_cat_item_guide^elementISNOTEMPTY

Determine which items to include using 'Rules' (sc_cat_item_guide_items)

Items to be included in a guide are held by sc_cat_item_guide_items (label 'Rule'). Each row represents 'which item to include and under what conditions.' There are 11 unique fields (including sys_id), and the following four are commonly used.

• guide (→ sc_cat_item_guide) ... Which guide the rule belongs to

• item (→ sc_cat_item) ... The catalog item to include

• condition (If this condition is true) ... The inclusion condition (references guide variables)

• order (At this position) ... The display order within the guide

The remaining 7 fields held by the rule

In addition to the four mentioned above, sc_cat_item_guide_items has seven other fields. These include quantity, show_quantity (whether to display the quantity field), and requested_by (the requester). The rest are requested_for (the user), ignore_mandatory_eval (whether to ignore mandatory checks), use_sc_layout (whether to use the catalog layout), and sys_id.

This is where the 'variables' held by the guide itself come into play. Since a guide is also an item, it can have questions displayed on the needs description screen as variables (item_option_new). The New Hire guide in this case had seven of its own variables.

• hiring_manager (Hiring Manager - Reference)

• hiring_group (Hiring Group - Reference)

• remote (Is remote work - Yes/No)

• corp_office (Work Office - Reference)

• standard_package (Is standard package sufficient - Yes/No)

• laptop_type (Device Type - Select Box)

• mobile_device_type (Mobile Device Type - Select Box)

The rule's condition determines whether to 'include' or 'not include' based on the values of these guide variables. Next is the actual Rule form (Developer Laptop (Mac)).'Include this item when laptop_type is Developer AND standard_package is Yes' is explicitly stated as the filter condition.

The diagram below illustrates how the 'Answer to Question → Items to Include' logic is differentiated.

The following table shows the 8 rules for the New Hire guide and their differentiation conditions. Rules with empty conditions (New Email Account / Corp VPN) are always included regardless of the answers.

You can check the list of rules at the following URL (filter by guide).

https://<YourInstance>/sc_cat_item_guide_items_list.do?sysparm_query=guide=<ガイドのsys_id>^ORDERBYorder

In this PDI, there were 8 rules for the New Hire guide and 12 rules for the Request Developer Project Equipment guide. Out of the 20 total rules, 18 have differentiation conditions, and the remaining 2 have no conditions (always included).

Flow from Needs Description to Bulk Request

The following is a summary of how the tables discussed so far interact, organized by the user's operational flow.

1. Needs Description: Answer the guide's variables (remote?, device type?, etc.)

2. Rule Evaluation: The condition in sc_cat_item_guide_items checks the answers and determines which items to include

3. Option Selection: Review the included items and fine-tune them using the include toggle

4. Bulk Request: Submit multiple included items together as a single Request

In this article, I verified the table structure and rule differentiation conditions on an actual instance. The actual rendering of Needs Description → Option Selection → Checkout, as well as the generation of RITM for each item, are outside the scope of this verification. The actual form behavior of cascade=true / two_step=true is also outside the scope (both OOTB guides had cascade and two_step set to false).

Observations from the actual instance

There is no 'Order Guide' value in the catalog 'Type' field

The choices for sc_cat_item.type are 1=Item, 2=Task, 3=Bundle, 4=Template, and 5=Package. 'Order Guide' is not included here. Looking at sys_dictionary on the actual instance, Order Guides do not use a method of adding to the type choices. Instead, they are implemented as a dedicated table, sc_cat_item_guide, which inherits from sc_cat_item.

Rule conditions can use OR as well as AND

Comparing the rules on the actual instance, the conditions were not limited to AND. Developer Laptop (Mac) uses an AND condition: laptop_type is Developer AND standard_package is Yes. On the other hand, Standard Laptop uses an OR condition: standard_package is No OR hiring_group is sales. Even within a single guide, there is the flexibility to change how conditions are structured for each item.

Key points of Order Guides in ServiceNow

• An Order Guide (sc_cat_item_guide) is not an independent entity, but a "special item" that inherits from Catalog Item (sc_cat_item). It inherits the name, category, associated catalogs, etc., from the item. There are only 7 unique fields (two_step / cascade / include_items / order_to_cart / script / validator / sys_id).

• The actual items included in a guide are stored in a separate table, sc_cat_item_guide_items (labeled "Rule"). Each row contains a reference to the guide and item, the condition for inclusion, and the order.

• The rule condition determines whether to "include" or "not include" an item by referencing the value of the guide's own variables (item_option_new). The condition verified on the New Hire guide was laptop_type=developer AND standard_package=Yes. When this is met, the Developer Laptop (Mac) is included.

• In this PDI (Zurich / OOTB), there were 2 order guides and 20 rules (18 with conditions / 2 without).

The starting point for investigating order guides is understanding their structural relationships. The guide itself (sc_cat_item_guide = special item) and the rules for the items to be included (sc_cat_item_guide_items) are in separate tables. From there, it is faster to track which guide variables the rule conditions are looking at as a set.

What to read next

There are three things I want to check next: how guide variables are passed to variables of the same name in each item when cascade=true is enabled; the actual form behavior of the "Describe Needs" to "Choose Options" flow when two_step=true; and the relationship between the Request (sc_request) generated by a bulk request and each Requested Item (sc_req_item). Since all of these go beyond the "guide-specific fields" and "rule-based inclusion" covered in this article, I plan to cover them in a separate article.

Terminology

Here is a summary of the terms used in this article.

• PDI: Personal Developer Instance (a free instance for testing)

• OOTB: Out of the Box (default settings)

• Order Guide: sc_cat_item_guide. A mechanism to bundle multiple items into a single request.

• Catalog Item: sc_cat_item. A single unit that a user requests from the catalog.

• Rule: sc_cat_item_guide_items. Defines the items to include in a guide and the conditions for their inclusion.

• Guide Variable: item_option_new held by the guide itself (questions answered in "Describe Needs")

• Cascade: A setting that passes the value of a guide variable to a variable of the same name in each item.

• Two Step: A setting that creates a two-stage configuration of "Describe Needs" followed by "Choose Options".

URLs for checking in your own environment

You can open the same screens by prepending your instance name.

ガイド一覧        : sc_cat_item_guide_list.do
ガイド本体（フォーム）: sc_cat_item_guide.do?sys_id=<ガイドのsys_id>
ガイドのルール一覧  : sc_cat_item_guide_items_list.do?sysparm_query=guide=<ガイドのsys_id>^ORDERBYorder
ポータルのガイド画面 : sp?id=sc_cat_item_guide&sys_id=<ガイドのsys_id>
ガイド固有フィールド : sys_dictionary_list.do?sysparm_query=name=sc_cat_item_guide^elementISNOTEMPTY
ルール固有フィールド : sys_dictionary_list.do?sysparm_query=name=sc_cat_item_guide_items^elementISNOTEMPTY

Reference Materials

Official Documentation (Zurich)

• Order guides … Overview of order guides. It is explained as a mechanism for submitting a single service catalog request that generates multiple items.

• Create an order guide … Procedure for creating an order guide. It explains the flow of creating a guide and adding rules (items to include).

• Cascade an order guide variable … Concept of cascading variables. It is explained as a mechanism for passing values entered on the initial screen to variables with the same name in each ordered item.

• SC Order Guide widget … Explanation of the SC Order Guide widget that displays order guides in the Service Portal.

Referenced Japanese explanations (General information)

• [ServiceNow] Basics of Order Guides (TechHarmony) … Explanation of the basic operation of order guides and the 'Describe Needs' screen.

• [ServiceNow] Execution order of Order Guides (TechHarmony) … Explanation of processing order control via Order Guide Sequential Fulfillment.

Related Articles

• ServiceNow Service Catalog Complete Guide: From one request form to fulfillment tasks — Order guides that bundle multiple items are also one of the "special catalog items" in the flow from request to fulfillment. You can check the overall picture here.

Verification Scope and Disclaimer

• Scope confirmed: Inheritance relationship of sc_cat_item_guide / sc_cat_item / sc_cat_item_guide_items. Number of unique fields and main fields/references for sc_cat_item_guide and sc_cat_item_guide_items. Selection options for sc_cat_item.type. Count of 2 order guides and 20 rules (18 with conditions / 2 without). Differentiation conditions for 7 variables and 8 rules in the New Hire guide. 12 rules for Request Developer Project Equipment. All were obtained from OOTB in PDI (Zurich / confirmed 2026-06-20).

• Scope not confirmed: Actual form behavior of cascade=true / two_step=true (both OOTB examples are false). Actual rendering of Describe Needs -> Option Selection -> Checkout, and the generation of Request (sc_request) / Requested Item (sc_req_item) for each item. Execution of validator / script fields. Internal implementation of whether condition (variable_conditions) evaluation is server-side or client-side. Behavior of the Order Guide Sequential Fulfillment plugin. These will be covered in a separate article.