The Service Catalog is most end users' main touchpoint with ServiceNow. Whether they are requesting a laptop, asking for VPN access, raising an HR query, or ordering office supplies — they almost always submit it through a catalog item. Mastering the catalog is mastering 60% of typical admin work.
Three Building Blocks
| Component | Purpose |
|---|---|
| Catalog item | A single requestable thing (Laptop, VPN access, Software license) |
| Record producer | A form that creates a record on any table (often used for "Submit Incident") |
| Order guide | A guided experience that bundles multiple catalog items (e.g., onboarding) |
The Request → Req Item → Task Chain
When a user orders catalog items, three records are created:
sc_request (Request — REQ0010001)
└── sc_req_item (Requested Item — RITM0010001)
└── sc_task (Catalog Task — SCTASK0010001)- sc_request — One per order (a shopping cart can contain multiple items)
- sc_req_item (RITM) — One per ordered item; the fulfillment status lives here
- sc_task (SCTASK) — One or more tasks assigned to fulfillers to actually deliver the item
All three tables extend task, so they share the standard task fields (assignment, state, priority) and benefit from task-wide automation.
Catalog Items
To define a catalog item, you specify:
- Name, short description, icon
- Category (e.g., Hardware, Software, Access) and Catalog (e.g., Service Catalog, HR Catalog)
- Price and recurring price (optional)
- Workflow or Flow that runs on submission
- Variables — the input fields the user fills in
- Order roles — which roles can order this item
Variables and Variable Sets
A variable is a question the user answers when ordering — "Which laptop model?", "Reason for VPN access?", "Manager approval contact?". Variable types include single-line text, multi-line text, choice, checkbox, reference, date, attachment, and more.
A variable set is a reusable group of variables that can be attached to multiple catalog items. A typical "user info" variable set might contain First Name, Last Name, Employee ID, Department, and Manager — reused across dozens of items.
Variables can be made:
- Read-only for some users (e.g., pre-filled from user profile)
- Mandatory conditionally (catalog UI policies)
- Visible based on other variables (cascading visibility)
Catalog UI Policies and Client Scripts
To make the catalog form dynamic — show fields only when relevant, validate input as the user types — you use:
- Catalog UI Policies: Declarative rules: "If 'Software needed' is true, make 'Software name' mandatory and visible."
- Catalog Client Scripts: Imperative JavaScript that runs in the browser, for more complex behaviour like calling an API to populate a dropdown.
Prefer UI Policies over Client Scripts whenever the requirement can be expressed declaratively — they are easier to maintain and faster.
Record Producers
A record producer looks like a catalog item but, on submit, creates a record on a different table — most commonly incident. This is how "Submit an Incident" forms are built on the Service Portal.
The producer maps variable values to fields on the target table via a small script:
// Record producer script
current.short_description = producer.short_description;
current.urgency = producer.urgency;
current.caller_id = gs.getUserID();Order Guides
An order guide is a multi-step experience that asks shared questions once, then orders multiple catalog items based on the answers. The canonical example is new hire onboarding:
- Step 1: Capture new hire info (name, start date, role, location)
- Step 2: Based on role, auto-include items: laptop, monitor, VPN access, Slack account, Jira license
- Step 3: Reviewer confirms and submits a single request
The order guide creates one sc_request with multiple sc_req_items, fanning out work to multiple fulfilment teams in parallel.
Workflows / Flows
Each catalog item has a workflow or flow attached. The workflow runs after submission and typically:
- Requests approval from the requestor's manager
- Creates one or more sc_task records assigned to fulfillment groups
- Sends notifications at each state change
- Closes the RITM when all tasks complete
Older catalog items use the legacy Workflow editor. Newer items use Flow Designer (which we will cover in lesson 6). Either way, the same RITM/SCTASK lifecycle applies.
Common Catalog Patterns
- Approval-then-task: Manager approves, then a fulfillment task is created
- Parallel tasks: Multiple teams work in parallel (e.g., AD account + laptop image + ID badge)
- Hardware procurement: Vendor integration via REST to place external order, then receive on delivery
- Birthright access: No approval; immediately provisioned (e.g., default applications for all new hires)
Service Portal
End users typically access the catalog via the Service Portal (e.g., company.service-now.com/sp) — a friendly, branded interface that hides the platform tables behind a clean shopping experience. The portal is a separate UI framework (built on AngularJS in legacy and Next Experience / Polaris in modern) but consumes the same catalog data.
Try It on Your PDI
- Open the Service Catalog (Catalog > Open Records > Items)
- Create a new item "Software License Request"
- Add variables for Software Name (string), Justification (multi-line), Manager Approval Required (boolean)
- Use the default catalog workflow to test the request flow
- Order it as yourself; watch sc_request → sc_req_item → sc_task created in sequence