Service Catalog

Section 1

Catalog Hierarchy

The Service Catalog is a structured, self-service portal where users can browse and request IT and business services. Understanding the three-level hierarchy is foundational to everything else in this topic.

Three-Level Structure

📚

1. Catalog (`sc_catalog`)

The top-level container. An instance can have multiple catalogs — for example, a separate IT Catalog, HR Catalog, and Facilities Catalog. Each catalog can have its own look, feel, and access restrictions.

Table: sc_catalog

📂

2. Category (`sc_category`)

Organizes catalog items within a catalog into logical groups. Categories can be nested (parent/child). Examples: "Hardware", "Software", "Access Requests".

Table: sc_category

🛒

3. Catalog Item (`sc_cat_item`)

The individual orderable item within a category. This is what users browse and add to their cart. Each item defines what information to collect (variables) and how to fulfill the request.

Table: sc_cat_item

Visual Hierarchy: Catalog → Categories → Catalog Items. Think of it like a shopping website: the store (catalog) has departments (categories) which contain individual products (catalog items). Multiple stores (catalogs) can coexist on the same platform.

Multiple Catalogs Support

ServiceNow natively supports multiple catalogs on a single instance. Common catalog examples include:

IT Service Catalog — Hardware, software, access requests
HR Catalog — Onboarding, benefits, policy documents
Facilities Catalog — Office supplies, building maintenance requests
Employee Self-Service (ESS) Catalog — Common employee requests

Each catalog can be associated with its own User Criteria to control who sees it. A single catalog item can appear in multiple catalogs.

Key Catalog Tables Summary

Table	Contains	Navigate To
`sc_catalog`	Catalog definitions (IT Catalog, HR Catalog, etc.)	Service Catalog > Catalogs
`sc_category`	Category groupings within catalogs	Service Catalog > Categories
`sc_cat_item`	All catalog items (all types stored here)	Service Catalog > Catalog Items
`sc_request`	Top-level requests (REQ) — the cart/order	Service Catalog > Requests
`sc_req_item`	Individual requested items (RITM)	Service Catalog > Requested Items
`sc_task`	Fulfillment tasks (SCTASK) generated from RITMs	Service Catalog > Tasks

Section 2

Catalog Item Types (CRITICAL Exam Topic)

There are four distinct catalog item types. Knowing the differences — especially what record each type creates — is one of the most tested areas on the CSA exam.

📋

1. Catalog Item

The standard, most common item type. When ordered, it creates an sc_req_item (RITM) record. Users add it to a shopping cart and check out.

Creates: RITM (sc_req_item)
Example: "Request a Laptop", "VPN Access Request"

⚡

2. Record Producer

Creates a record in any target table — not just catalog tables. Bypasses the shopping cart entirely and submits directly. Used to create incidents, problems, or any custom table record through a catalog-style form.

Creates: Any table record (incident, problem, custom)
Example: "Report an IT Issue" (creates an Incident)

📦

3. Order Guide

Groups multiple catalog items that must be ordered together as a bundle. Uses a mandatory two-step checkout process: Step 1 (collect guide-level info) and Step 2 (customize individual items). Items in an order guide are ordered simultaneously.

Creates: Multiple RITMs (one per included item)
Example: "New Employee Setup" (laptop + software + badge)

🔗

4. Content Item

Does not create any record. Links to an external URL, a Knowledge Base article, or other content. Used to surface reference material within the catalog browsing experience.

Creates: Nothing
Example: "VPN Setup Guide" → links to KB article

Comparison Table — All Four Item Types

Item Type	Record Created	Uses Shopping Cart?	Checkout Steps	Primary Use Case
Catalog Item	`sc_req_item` (RITM)	Yes	Standard (1 step)	Standard IT/service requests (hardware, software, access)
Record Producer	Any target table (incident, problem, custom)	No — direct submit	None (direct)	Friendly front-end form for creating records in non-catalog tables
Order Guide	Multiple RITMs (one per bundled item)	Yes	Mandatory 2-step	Bundle of items that must always be ordered together
Content Item	None	No	None (redirect)	Link to documentation, KB articles, or external URLs

Exam Must-Know — Record Producer: A Record Producer bypasses the shopping cart and goes directly to the target table. It does NOT create an sc_req_item. Instead it creates a record in whatever table you configure (e.g., incident, problem, or a custom table). This is a very common exam distractor — do not confuse it with a Catalog Item.

Exam Must-Know — Order Guide: An Order Guide uses a mandatory two-step checkout. Step 1 collects order-guide-level variables. Step 2 shows the individual items in the bundle and allows per-item customization. You cannot skip the two-step process — it is always enforced for Order Guides.

When to Use Which: Use a Catalog Item for standard requests. Use a Record Producer when you want a user-friendly form that creates non-catalog records (like incidents). Use an Order Guide when a set of items must always be requested together (e.g., new hire onboarding bundle). Use a Content Item to surface documentation or links without creating any transactions.

Section 3

Variables — Item Configuration

Variables are the form fields that collect information from the requester when they order a catalog item. They define what data to gather during the ordering process and that data travels with the RITM through fulfillment.

Variable Types

Variable Type	Input Method	Common Use
Single Line Text	Single-line text input	Short answers — names, phone numbers, asset tags
Multiple Line Text	Multi-line text area	Descriptions, justifications, additional details
Select Box	Dropdown list of options	Priority, department, location choices
Check Box	True/false toggle	Acknowledgments, yes/no options, confirmations
Date	Date picker widget	Requested delivery date, start date, end date
Reference	Reference lookup field to another table	Selecting a manager, CI, user, location from another table
Attachment	File upload control	Uploading justification documents, images, forms
Label	Read-only display text (no input)	Section headers, instructional text, dividers
Macro	Renders a UI Macro on the form	Custom widgets, complex display logic
UI Page	Embeds a full UI Page	Complex custom forms, multi-step embedded content

Variable Sets — Reusable Variable Groups

A Variable Set is a reusable collection of variables that can be attached to multiple catalog items. Instead of recreating the same variables on every item, you define them once and reuse them.

What is a Variable Set?

A saved group of variables stored in item_option_new_set (variable set definition) that can be linked to any number of catalog items via io_set_item.

Why Use Variable Sets?

Consistency and maintainability. If the common "Justification" and "Manager Approval" fields need updating, you change the Variable Set once and all linked items inherit the change.

Two Types of Variable Sets

One-to-Many: Standard set — same variables across multiple items.
Single-Row: Displays each row as a single entry (used in Order Guides).

Exam Point — Variable Sets: Variable Sets can be shared across multiple catalog items. This is a key reusability feature. Know that changes to a Variable Set propagate to all catalog items that include it — making them the preferred approach for common variable groups (like "Business Justification" or "Contact Information").

Variable Configuration Options

Order — Controls the display sequence of variables on the form (lower number = appears first)
Mandatory — Checkbox; when checked, the requester must fill in this field before submitting
Default value — Pre-populates the field with a value; the requester can still change it
Show/Hide conditions — Dynamic visibility rules: show this variable only when another variable has a specific value
Read only — Displays the variable but prevents the requester from changing it
Active — Inactive variables are hidden from the catalog form without being deleted
Help text — Tooltip or inline guidance text displayed to the requester
Variable name — Internal identifier used in scripts (e.g., cat_item.variables.business_justification)

Variable Data Flow: When a user fills out variables and submits, the answers are stored in the sc_item_option_mtom table (linking RITM to variable answers) and in sc_item_option (the actual answers). Fulfillment agents can view all variable answers on the RITM form in the "Variables" tab.

Section 4

Request Fulfillment Tables (CRITICAL Exam Topic)

Understanding the three-tier fulfillment hierarchy is essential. The CSA exam tests this hierarchy frequently — know the table names, abbreviations, and the parent-child relationship.

The REQ → RITM → SCTASK Hierarchy

🛒

REQ — `sc_request`

The top-level request, equivalent to the shopping cart or entire order. One REQ is created per checkout action, regardless of how many items are in the cart.

Number prefix: REQ
Example: REQ0001234
Represents: The whole order/cart

📝

RITM — `sc_req_item`

An individual line item within a request. If a user orders 3 items in one cart, 3 RITMs are created — each linked to the parent REQ. Fulfillment teams work on RITMs, not REQs.

Number prefix: RITM
Example: RITM0001234
Represents: One ordered item

✅

SCTASK — `sc_task`

A fulfillment task generated by the catalog workflow to fulfill a RITM. One RITM can generate multiple SCTASKs assigned to different teams. SCTASKs are how work is distributed to fulfillment agents.

Number prefix: SCTASK
Example: SCTASK0001234
Represents: A fulfillment work item

Exam Must-Know — REQ vs. RITM: The REQ is the entire cart/order. The RITM is an individual line item. If a user checks out with 5 items in their cart, ServiceNow creates 1 REQ and 5 RITMs. Fulfillment workflows are triggered at the RITM level, not the REQ level. Always remember: RITM = individual line item.

State Flows

Table	State Flow	Notes
sc_request (REQ)	Requested → In Progress → Closed Complete / Closed Incomplete / Closed Cancelled	REQ state rolls up from its child RITMs; when all RITMs close, REQ closes
sc_req_item (RITM)	Requested → Approved → In Progress → Fulfilled → Closed Complete	Approval step optional (configured in workflow); fulfillment workflow drives state transitions
sc_task (SCTASK)	Open → Work In Progress → Closed Complete / Closed Incomplete / Closed Skipped	Inherits from the base `task` table; assignment group drives routing

Table Inheritance

sc_task Extends task: The sc_task table extends (inherits from) the base task table. This means SCTASKs have all standard task fields (assignment group, assigned to, state, priority, short description, comments, work notes, etc.) plus catalog-specific fields. This is an exam-tested fact — know that sc_task is a child of the task table.

Ordered Item Link

The Ordered Item Link is the relationship that connects a RITM to the specific variable answers the requester submitted. This allows fulfillment agents to see exactly what options were selected when the user placed the order.

Variable answers are accessible from the RITM in the "Variables" related list/tab
Scripts can access variable values via current.variables.variable_name on the RITM record
All variable answers persist with the RITM through its entire lifecycle

Section 5

Catalog Client Scripts & UI Policies

Catalog items support their own client-side scripting and UI policies. These are distinct from standard form client scripts and UI policies — they apply only to the catalog ordering form, not to regular table forms.

Catalog Client Scripts

Catalog Client Scripts run in the requester's browser during the catalog ordering experience. They behave similarly to standard client scripts but operate on catalog variables rather than record fields.

Aspect	Catalog Client Script	Standard Client Script
Applies to	Catalog item ordering form (variables)	Table record form (fields)
Script scope	Catalog item or Variable Set	Specific table
Access variables via	`g_form.getValue('variable_name')`	`g_form.getValue('field_name')`
Types supported	onChange, onLoad, onSubmit	onChange, onLoad, onSubmit, onCellEdit
Table	`catalog_script_client`	`sys_script_client`

Catalog Client Script Types

onLoad

Runs when the catalog item form first loads in the browser. Used to set default values, show/hide variables based on context, or initialize dynamic content.

onChange

Fires when the value of a specific variable changes. Used for cascading logic — e.g., when "Location" changes, filter the "Manager" reference field to show only that location's managers.

onSubmit

Runs just before the form submits. Used for client-side validation — e.g., ensure two date variables are in the correct order before allowing submission. Return false to block submission.

Catalog UI Policies

Catalog UI Policies control the visibility, mandatory, and read-only state of variables on the catalog ordering form without requiring JavaScript. They are the catalog equivalent of standard UI Policies.

Navigate to: Service Catalog > Catalog UI Policies
Conditions reference catalog variables (not table fields)
Actions can make variables: Visible/Hidden, Mandatory/Optional, Read Only/Editable
Can apply to a specific catalog item or a Variable Set (for reuse)
Run client-side — cannot be used as a security enforcement mechanism

Key Distinction: Catalog Client Scripts and Catalog UI Policies are separate from standard Client Scripts and UI Policies. They are stored in different tables and configured through different navigators. A standard UI Policy does NOT apply to a catalog item's ordering form — you need a Catalog UI Policy for that.

Catalog UI Policy vs. Catalog Client Script: Use a Catalog UI Policy for simple show/hide/mandatory/read-only logic driven by conditions — no coding required. Use a Catalog Client Script when you need programmatic logic: calling a GlideAjax, performing calculations, or handling complex multi-variable interactions.

Section 6

Access Control for Catalog

The Service Catalog uses a dedicated access control mechanism called User Criteria — this is different from the ACL system used elsewhere in ServiceNow. Understanding User Criteria is critical for the exam.

User Criteria

User Criteria define sets of users based on roles, groups, companies, departments, or locations. These criteria are then applied to catalog items (and catalogs/categories) to control who can see and order them.

What User Criteria Can Match On

Roles — User has specific role(s)
Groups — User is member of group(s)
Companies — User's company
Departments — User's department
Locations — User's location
Users — Specific named user(s)
Script — Custom boolean script for complex conditions

Where User Criteria Are Applied

Catalog (entire catalog visibility)
Category (category visibility)
Catalog Item (item visibility and orderability)
Can be applied at multiple levels simultaneously

Available For vs. Not Available For

Field	Effect	Example
Available for	Explicitly grants visibility/ordering to matched users. If populated, only matching users see the item.	"Available for" = IT Staff group → Only IT Staff see this item in the catalog
Not available for	Explicitly denies visibility/ordering to matched users, even if they match the "Available for" criteria.	"Not available for" = Contractors → Contractors cannot order this item even if in the IT group

Logic: The effective access = "Available for" MINUS "Not available for". "Not available for" takes precedence over "Available for". If a user matches both criteria, they are denied access. If neither field is populated, the item is visible to all authenticated users by default.

Testing Catalog Access

ServiceNow provides a built-in tool to verify catalog visibility for specific users without impersonating them.

"Try it" / "Try as user" button — available on catalog item records; lets admins preview how the item appears to a specific user
Impersonation — admins can impersonate any user to fully test the catalog experience from that user's perspective
User Criteria Diagnostics — evaluate which User Criteria rules match for a given user

Exam Point — User Criteria vs. ACLs: Catalog access is controlled by User Criteria, NOT by ACLs. ACLs still apply to the underlying tables (sc_cat_item, sc_req_item, etc.) for data-level security, but the catalog browsing/ordering visibility is governed exclusively by User Criteria. This is an important distinction.

Section 7

Workflow & Flow Designer for Fulfillment

After a user submits a catalog item, the fulfillment process is driven by either a Catalog Workflow (legacy) or a Flow Designer flow (modern approach). Both automate the steps required to fulfill the request.

Catalog Workflows (Legacy)

Catalog Workflows are workflow-engine based automations attached to catalog items. They trigger automatically when a RITM is created.

Trigger

Catalog workflows are triggered on RITM creation (when the user submits the catalog order). One workflow instance runs per RITM.

Approval Steps

Workflows can include approval activities — pausing the RITM in "Waiting for Approval" state until a designated approver approves or rejects. Approvals can be manual or automated.

Task Generation

The workflow generates SCTASK records using the "Catalog Task" workflow activity. These tasks are assigned to fulfillment teams and must be closed before the workflow advances.

Configuration

Assigned on the catalog item record in the "Process Engine" tab or "Workflow" field. Navigate to: Workflow > Workflow Editor to build/modify.

Flow Designer (Modern Replacement)

Flow Designer is ServiceNow's modern, low-code automation platform. It replaces the legacy Workflow editor with a more intuitive drag-and-drop interface and better integration with the Now Platform.

Aspect	Catalog Workflow (Legacy)	Flow Designer (Modern)
Interface	Drag-and-drop visual workflow editor	Modern step-by-step flow builder (no-code/low-code)
Trigger	RITM creation (workflow context)	Service Catalog trigger (RITM-based or direct)
Actions	Workflow activities (Catalog Task, Approval, etc.)	Action library (Create Task, Ask for Approval, etc.)
Recommended for	Legacy instances, existing workflows	New development — ServiceNow recommended
Access	Workflow > Workflow Editor	Process Automation > Flow Designer

CSA Exam Guidance: The CSA exam covers both approaches. Know that Flow Designer is the modern replacement for the legacy Workflow engine and that ServiceNow recommends it for new catalog fulfillment automation. Understand that both can generate SCTASKs and include approval steps.

Typical Fulfillment Flow

User submits catalog item
  ↓
REQ created (sc_request) — state: Requested
  ↓
RITM created (sc_req_item) — state: Requested
  ↓
Workflow / Flow triggered on RITM
  ↓
[Optional] Approval activity → RITM state: Waiting for Approval
  ↓ (approved)
SCTASK generated (sc_task) — assigned to fulfillment team
  ↓
Fulfillment team works on SCTASK → closes it
  ↓
RITM state updates: Fulfilled / Closed Complete
  ↓
When all RITMs under REQ close → REQ auto-closes

Section 8

Key Exam Facts & Critical Reminders

This section consolidates the most exam-critical facts about the Service Catalog. Review this before your exam — these points are directly tested.

Fact 1 — RITM is the line item, REQ is the cart: A user ordering 3 items creates 1 REQ and 3 RITMs. Fulfillment workflows attach to the RITM, not the REQ. Fulfillment agents work RITMs and SCTASKs — never the REQ directly.

Fact 2 — Record Producer bypasses the cart: A Record Producer goes directly to the target table without creating a shopping cart or RITM. It creates a record in whatever table you configure (incident, problem, custom table). It does NOT go through sc_request or sc_req_item.

Fact 3 — Order Guide enforces 2-step checkout: The Order Guide's two-step checkout is mandatory and cannot be skipped. Step 1 is the Order Guide-level form. Step 2 is individual item customization. An Order Guide creates multiple RITMs — one for each bundled catalog item.

Fact 4 — Variable Sets are shared/reusable: A Variable Set can be attached to multiple catalog items. Updating the Variable Set affects all linked items. This is the preferred approach for common variable groups across many catalog items.

Fact 5 — sc_task extends the task table: The sc_task table (SCTASK) inherits from the base task table. It has all standard task fields plus catalog-specific fields. This means assignment groups, SLAs, and task management features work on SCTASKs exactly as they do on incidents and other task-based records.

Fact 6 — Catalog access uses User Criteria, not ACLs: Who can see and order catalog items is controlled by User Criteria (the "Available for" and "Not available for" fields). Standard ACLs control the underlying table data security but not catalog browsing/ordering visibility.

Fact 7 — Content Item creates nothing: A Content Item does not create any record in ServiceNow. It simply redirects the user to an external URL or KB article. There is no RITM, no REQ — nothing transactional happens.

Fact 8 — Catalog Client Scripts are distinct from standard Client Scripts: They are stored in a different table (catalog_script_client) and apply only to the catalog ordering form. You cannot use a standard Client Script to control catalog variables — you must use a Catalog Client Script or Catalog UI Policy.

Full Hierarchy Quick Reference

Level	Object	Table	Number Prefix	Created By
1 (Top)	Request	`sc_request`	REQ	System — on checkout
2	Requested Item	`sc_req_item`	RITM	System — one per ordered item
3	Catalog Task	`sc_task`	SCTASK	Workflow/Flow — one per fulfillment step

Catalog Item Type Quick Reference

Type	Creates	Cart?	Steps	Use When…
Catalog Item	RITM (`sc_req_item`)	Yes	1	Standard IT/service request
Record Producer	Any record (incident, etc.)	No	Direct	User-friendly form for non-catalog records
Order Guide	Multiple RITMs	Yes	2 (mandatory)	Bundle of related items always ordered together
Content Item	Nothing	No	Redirect	Surface links/documentation in the catalog

Putting It All Together — Full Catalog Flow:

Admin creates a Catalog (sc_catalog) and Categories (sc_category) to structure the offering
Admin creates Catalog Items (sc_cat_item) with Variables to collect requester info
Admin attaches User Criteria ("Available for") to control who sees each item
Admin builds a Workflow or Flow to automate approval and SCTASK generation
User browses the catalog, fills in variables, checks out → REQ + RITM created
Workflow triggers on RITM → generates SCTASKs for fulfillment teams
Fulfillment team closes SCTASKs → RITM closes → REQ closes