4.1 Service Catalog & Request Fulfillment

Why the Service Catalog Matters for the CSA Exam

The Service Catalog is the front door for self-service on the ServiceNow platform. Instead of emailing IT or filing a vague ticket, users browse a structured storefront of offerings — a new laptop, software access, password resets — each backed by defined data capture and an automated fulfillment path. Because Self Service and Automation is a 20% domain on the CSA blueprint, expect questions on how a request flows through the platform and which table each record lands on.

The catalog matters because it standardizes intake. A well-built catalog item collects exactly the information fulfillment teams need, routes work automatically, and gives requesters a status they can track without opening a ticket with the service desk.

The Request Fulfillment Record Model

When a user submits a catalog order, ServiceNow creates a small hierarchy of records. The CSA exam frequently asks which record represents what, so memorize this structure.

One REQ can contain several RITM records when a cart holds multiple items. Each RITM can spawn one or more SCTASK records — for example, an "approve" task, a "provision laptop" task, and a "ship hardware" task. Fulfillers usually work the SCTASK; the RITM and REQ close as their child work completes.

Visualizing the Flow

Catalog Items

A catalog item is a single orderable offering. It defines a name, short description, picture, category placement, the variables that collect input, and the fulfillment process (a flow, workflow, or task definition) that runs when the item is ordered. Items live on the sc_cat_item table and are placed into one or more catalogs and categories for navigation.

Catalog item types you should recognize for the exam:

• Catalog Item — a standard orderable service or product that follows the REQ/RITM/SCTASK model.
• Record Producer — a simplified intake form that creates a record on a target table directly.
• Order Guide — a guided flow that bundles several catalog items into one ordering experience.
• Content Item — a non-orderable informational tile (a link or instructions, no fulfillment).

Record Producers

A record producer is a special catalog item that creates a record on any table you choose — most commonly Incident (incident) — using a friendly, variable-driven form. Instead of generating REQ, RITM, and SCTASK records, the record producer maps variables directly to fields on the target record.

Use a record producer when the goal is to create a single business record (an incident, a change request, an HR case) through a guided form rather than to fulfill a multi-step service order. A classic example is a "Report an Outage" form that creates a high-priority incident with the right category and assignment group pre-set.

Order Guides

An order guide ties multiple catalog items into one sequenced ordering process. The requester answers a set of questions once, and the order guide uses rule bases to decide which items to include and to pass shared answers into each item's variables.

The textbook use case is employee onboarding: a single order guide collects the new hire's department, location, and role, then assembles a laptop request, a phone request, building access, and software entitlements into one cart. Each included item still produces its own RITM, all grouped under one REQ.

Variables and Variable Sets

Variables are the input fields on a catalog item — single-line text, reference, choice, checkbox, lookup select box, and more. Each variable's answer is stored with the RITM and is visible to fulfillers.

A variable set is a reusable, ordered collection of variables that can be attached to many catalog items. Variable sets prevent duplication: if every hardware request needs the same shipping-address and cost-center questions, build those once in a variable set and reuse it. A variable set can be a standard set or a single-row/multi-row variable set (MRVS) that captures repeating rows of data.

Catalog UI Policies and Catalog Client Scripts

Standard UI policies and client scripts run against records on a table form. The catalog uses parallel, catalog-specific tools because variables are not native table fields:

• Catalog UI Policy — declaratively makes a variable mandatory, visible, or read-only based on conditions on other variables. No scripting required for common cases.
• Catalog Client Script — runs JavaScript in the browser on the catalog item form for onLoad, onChange, onSubmit, or onCellEdit events to manipulate variables dynamically.

Both are scoped to a specific catalog item or variable set. A frequent exam distinction: to control variable behavior on the catalog form, use a catalog UI policy or catalog client script — not the regular table UI policy, which targets the underlying record fields, not the variables.