Week 15: Catalog Client Scripts, UI Policies & Variable Sets

1. Catalog Items & Variables

A Catalog Item (sc_cat_item) is a requestable thing — "New Laptop," "VPN Access" — defined not by a dedicated table schema but by a list of Variables (item_option_new): the catalog's answer to form fields, each with a type (Single Line Text, Reference, Select Box, Checkbox, and more) configured entirely declaratively.

2. Variable Sets

A Variable Set groups related variables so they can be reused across multiple catalog items without redefining them each time — the catalog equivalent of a shared form-fragment component. Once a variable set exists, attaching it to a catalog item pulls in its whole group of variables at once.

3. Catalog Client Scripts & the Portal `g_form`

Catalog Client Scripts are Week 3's Client Scripts, adapted for the catalog's variable-driven forms — same onLoad/ onChange/onSubmit event model, same g_form API shape, applied to variables instead of table fields, and runnable in both the classic UI's catalog form and the Service Portal catalog item page.

Catalog Client Script — onChange, on variable "equipment_type"

function onChange(control, oldValue, newValue, isLoading) {
  if (isLoading || newValue === '') return;

  if (newValue === 'laptop') {
    g_form.setDisplay('screen_size', true);
    g_form.setMandatory('screen_size', true);
  } else {
    g_form.setDisplay('screen_size', false);
    g_form.setMandatory('screen_size', false);
  }
}

If Week 3's g_form.setVisible()/setMandatory() felt familiar there, it should feel familiar here too — it's genuinely the same client-scripting model, applied to a different kind of form.

4. The Request Workflow: REQ → RITM → Tasks

Submitting a catalog item doesn't create one record — it creates a chain:

Request (sc_request, "REQ...") — the top-level container, one per submission (which can hold multiple items in a cart).
Requested Item (sc_req_item, "RITM...") — one per catalog item in the request, holding the actual submitted variable values.
Catalog Task (sc_task, "SCTASK...") — one or more fulfillment tasks generated from the RITM's workflow, assigned to whoever actually does the work.

Recall from Week 2: sc_req_item and sc_task both extend task, same as incidents — which is exactly why the ITSM modules starting next week will feel structurally familiar even though they're a different process end to end.

5. Hands-on Exercise

Hands-on

Build and submit a "New Equipment Request" catalog item

Requirements:

Create a catalog item with variables: a Select Box equipment_type (Laptop / Monitor / Keyboard), a Single Line Text screen_size, and a Multi Line Text justification.
Write the Catalog Client Script shown above so screen_size only shows for Laptop.
Submit the item through your Service Portal (from Week 9's portal), then find the resulting REQ, RITM and SCTASK records and confirm they're linked correctly.
Confirm the RITM's variable values match what you submitted by opening its "Variables" related list.

6. Knowledge Check

Four quick questions. Expand each to check your answer.

How is a catalog item's "schema" different from a regular table's dictionary-driven form?

A catalog item isn't defined by a dedicated table with dictionary entries — it's defined by a list of Variables (item_option_new records) attached to it, each with its own type. The catalog's form is generated from those variables rather than from a fixed table schema, which is what makes variable sets reusable across many different catalog items.

What problem does a Variable Set solve?

It groups related variables so they can be attached to multiple catalog items at once and reused, instead of redefining the same set of fields separately on every catalog item that needs them — the catalog equivalent of a shared, reusable form fragment.

How does a Catalog Client Script relate to the Client Scripts covered in Week 3?

It's the same event model and g_form API (onLoad/onChange/onSubmit, setMandatory, setDisplay, etc.) applied to catalog variables instead of table fields, and runnable both in the classic catalog form and in a Service Portal catalog item page.

What three record types typically get created when a user submits a catalog item, and how do they relate?

A Request (sc_request, "REQ...") as the top-level container for the submission; one Requested Item (sc_req_item, "RITM...") per catalog item in that request, holding the submitted variable values; and one or more Catalog Tasks (sc_task, "SCTASK...") generated from the RITM's workflow for whoever fulfills the request. sc_req_item and sc_task both extend task, the same base hierarchy incidents and problems extend.