Service Catalog and Request Fulfillment
Structure
A service catalog contains categories and catalog items. An item defines the questions users answer (variables, often grouped into variable sets), pricing, fulfilment flow, and approval logic. Record producers look like catalog items but create a record on another table instead of a requested item. Order guides bundle several items into one submission. Multi-row variable sets capture repeating data such as a list of new starters.
The three-level record chain
Submitting an item creates a request (sc_request, numbered REQ), which contains one or more requested items (sc_req_item, numbered RITM), which in turn generate catalog tasks (sc_task). Answers are stored as question-answer records linked to the requested item, not as columns on the item. Approvals are separate records tied to the request or item depending on configuration.
Fulfilment
Fulfilment is driven by flows or workflows triggered on the requested item, producing tasks for the groups that must act. State progression runs from Open through Work in Progress, then Closed Complete or Closed Incomplete. Availability of items is controlled by catalog and category publication plus user criteria, and by the item's own active flag.
Traps
Mixing up REQ and RITM when a question asks what a task rolls up to. Assuming variables are fields on the requested item. Assuming a record producer creates a requested item. Assuming an item is orderable simply because it exists - check active state, catalog publication, and user criteria.
Worked example
A new starter needs a laptop and an email account. Two catalog items, submitted together, produce one request, two requested items, and catalog tasks for hardware and identity teams, with an approval on the laptop item. Because both are wanted rather than broken, they are requests, not incidents. Rule of thumb: one submission equals one REQ; each line equals one RITM; each team action equals one catalog task.