Request Fulfillment / Service Catalog
About 25% of the CIS-ITSM exam — see all 6 domains.
The REQ → RITM → SCTASK model
This domain tests the request data model relentlessly. When a user orders from the Service Catalog:
- One Request (REQ) record is created per order (the "shopping cart" container). Table:
sc_request. - One Requested Item (RITM) is created per item in the cart, as a child of the REQ. Table:
sc_req_item. - Zero or more Catalog Tasks (SCTASK) are created as children of each RITM to capture the actual fulfillment work. Table:
sc_task.
All three extend task. The hierarchy is REQ (parent) → RITM (child) → SCTASK (grandchild). A REQ always has at least one RITM; SCTASKs are optional and exist only where work needs assigning. Closure flows up: SCTASKs close → RITM closes → REQ closes. A common exam trap: the RITM is what the customer requested and carries customer-facing additional comments; the SCTASK is where the assigned worker does the work and writes internal work notes.
Catalog building blocks
- Catalog items — the orderable products/services, organized into categories within one or more catalogs.
- Variables and variable sets — the questions presented to the requester; their answers (variable values) flow to RITM and can be passed to SCTASKs.
- Record producers — catalog-style forms that create a record on any table (e.g., create an incident from the portal) rather than ordering an item.
- Order guides — bundle multiple related items into a single guided ordering experience (e.g., onboarding).
- Catalog UI policies and catalog client scripts — control variable behavior on the catalog form.
Fulfillment automation: Flow Designer
Modern fulfillment is driven by Flow Designer flows (and the legacy graphical Workflow in older content) attached to the catalog item. A flow generates the SCTASKs, routes approvals, updates state, and closes records. Knowing that Flow Designer is the current automation engine (replacing legacy workflows) is exam-relevant.
Access and presentation
Catalog item and category visibility is governed by User Criteria (the same Available For / Not Available For mechanism used in Knowledge), letting you target who can see and order each item. Items surface through the Service Portal and the Employee Center (the current self-service experience).
Exam focus
- REQ (
sc_request) → RITM (sc_req_item) → SCTASK (sc_task); all extendtask. - One RITM per cart item; SCTASK optional; closure rolls upward.
- Variables/variable sets carry the request data; record producers create records on other tables; order guides bundle items.
- Flow Designer is the current fulfillment engine.
- User Criteria controls catalog visibility; Employee Center / Service Portal deliver it.
Sample questions from this domain
Three of the 75 in this domain, with the reasoning. The full set is in the question bank.
What is the primary purpose of the Service Catalog in ServiceNow?
- A. To present a structured, self-service list of available services and items that users can request ✓
- B. To document root causes of incidents
- C. To store configuration items and relationships
- D. To approve and schedule changes
Why: The Service Catalog presents a structured, self-service list of requestable services and items. Storing CIs (B) is the CMDB, approving changes (C) is Change Management, and documenting root cause (D) is Problem Management.
Which record is created when a user submits a service catalog order, serving as the overall container for the order?
- A. Catalog Task (sc_task)
- B. Request (sc_request) ✓
- C. Requested Item (sc_req_item)
- D. Incident
Why: Submitting an order creates a Request (sc_request) that contains the requested items. The Requested Item (B) represents each ordered item, the Catalog Task (C) is fulfillment work, and an Incident (D) is unrelated to a catalog order.
Which record represents a single item that was ordered within a request?
- A. Request (sc_request)
- B. Problem
- C. Requested Item (sc_req_item) ✓
- D. Change Task
Why: Each ordered item is a Requested Item (sc_req_item) within the parent Request. The Request (B) is the container, a Change Task (C) belongs to Change Management, and a Problem (D) is a different record type.