A catalog item gets a new variable, the workflow gets an extra approval step, and a hundred in-flight requests submitted under the previous design either silently skip the new approval or fail validation against fields that did not exist when they were submitted. The platform does not version catalog items the way it versions workflows. The discipline is yours to build.
Treat the catalog item as immutable per submission
The submission record (sc_request and sc_req_item) should capture the full state of the catalog item at submission time — variable definitions, default values, workflow reference. Future edits to the catalog item do not change the historical submission’s behavior. The platform partially supports this for variables (snapshotted on sc_item_option_mv); workflows are referenced by name and not snapshotted, which is where most breakage hides.
Use named workflow versions
When a catalog item references a workflow, reference a specific published version, not the “current” version. The sc_cat_item.workflow field defaults to track current, which means in-flight requests pick up the new workflow definition mid-stream. Override to a fixed version per item revision. When the catalog item itself revises, both the variables and the workflow version advance together.
catalog_item: New Hire Laptop v3
variables: snapshot v3
workflow: NewHireLaptopFlow v5 (pinned)
catalog_item: New Hire Laptop v4
variables: snapshot v4
workflow: NewHireLaptopFlow v6 (pinned)Variable additions need a default
Adding a new required variable to an existing catalog item retroactively makes every in-flight request “invalid” the next time something validates the form. Always add new variables as optional, or add with a sensible default that applies to in-flight requests. Promote to required only after the in-flight queue has drained.
Use Variable Sets for shared groups
A “delivery address” variable set used across 12 catalog items means one edit propagates to 12 items. Use Variable Sets explicitly for this leverage but version them deliberately — a careless edit to a shared set breaks 12 items at once. Treat shared Variable Sets like shared libraries; they need their own change discipline.
Major changes belong on a new item
If the change is large enough that in-flight reconciliation is impractical, retire the old item and publish a new one. The old item enters “expired” state (still visible to in-flight, hidden from new submissions), the new item takes the canonical name and short description. Migrating in-flight requests across items is messy; sometimes accepting the dual-version period is the right answer.
// On retire of an old catalog item
function retireItem(itemSysId, replacementSysId) {
var item = new GlideRecord('sc_cat_item');
item.get(itemSysId);
item.active = false;
item.expired = true;
item.replacement = replacementSysId;
item.update();
}Approval rules need version awareness
If the approval rule on a catalog item changes (new approver, new condition), in-flight requests should follow the rule that was in effect at submission, not the current rule. This requires snapshotting the approval definition or re-deriving it from the request’s submitted timestamp. Most teams skip this and just absorb the inconsistency; for compliance-sensitive items (financial requests, security access), proper versioning is non-negotiable.
Common failure modes
Variable label changed mid-stream — historical requests display the new label even though the field meaning may have shifted. Snapshot the label on the request item too. Catalog item retired without expiring the link — orphaned bookmarks and search hits land users on dead pages. Use a redirect rule to the replacement item.
Implementation sequence
Inventory the high-volume items first (top 20 by submission count). Apply the snapshot pattern, pinned workflow versions, and retirement-with-replacement to those. Lower-volume items can adopt the pattern as they next change. Trying to retrofit every catalog item on day one stalls in catalog refactor purgatory.
What changed in 2026
The Workflow Studio integration (where adopted) makes pinned-version references the default rather than an option. If your shop has migrated from Flow Designer to Workflow Studio, version pinning is enforceable; on legacy Flow Designer, you implement it via discipline.
What to do this week: query sc_req_item joined to sc_cat_item for in-flight requests where the item has revised since submission — that count is your in-flight versioning exposure.
