What This Table Is

The item_option_new_set table stores variable sets — reusable collections of catalog variables that can be attached to multiple catalog items. Variable sets solve the problem of duplicating common variable groups like "Server Specifications" or "Approval Details" across dozens of catalog items. Instead of recreating the same variables on each item, you define them once in a variable set and reference that set.

This table is owned by the Service Catalog module and supports the end-to-end catalog ordering process. When users order catalog items, variable sets contribute their variables to the item's ordering form. The variables from sets are merged with the item's direct variables to create the complete user experience. Variable sets can be conditional — appearing only when certain criteria are met.

The item_option_new_set table does not extend any other table — it's a standalone entity. However, it has tight relationships with item_option_new (individual variables), sc_cat_item_producer (catalog items), and the junction table io_set_item that links sets to items.

In large enterprises, expect 50-200 variable sets with 5-15 variables per set. Unlike catalog items which can number in thousands, variable sets stay relatively manageable. The table performs well at scale, but complex conditional logic on variable sets can slow catalog form rendering when you have deeply nested variable dependencies.

When You'll Script Against This Table

You'll primarily script against item_option_new_set in Catalog Client Scripts when building dynamic variable set visibility, Script Includes for catalog utilities, and Business Rules when automating variable set management. Background Scripts are common for bulk operations like activating sets across multiple catalog items or migrating variable configurations. Scheduled Jobs may query this table to audit variable set usage or clean up unused sets.

Access requires the catalog role for read operations and catalog_admin for modifications. In scoped applications, variable sets are scoped to the application that created them, which affects cross-scope variable set reuse.

Common scripting patterns:

  • Clone variable sets when creating new catalog items with similar variable groups
  • Bulk activate or deactivate variable sets based on business rules or seasonal requirements
  • Query variable sets by category to build dynamic catalog navigation or filtering
  • Audit which catalog items use specific variable sets before making breaking changes
  • Programmatically assign variable sets to catalog items during bulk catalog imports
  • Generate reports on variable set reuse and consolidation opportunities
  • Synchronize variable set changes across development environments during deployment

Table Gotchas

⚠️

Variable sets have their own active field separate from their associated catalog items. A variable set can be active while attached to an inactive catalog item, or inactive while attached to an active item. Always check both states.

  • The order field controls display sequence on catalog forms, but it's relative to other variable sets on the same item, not global ordering across all sets
⚠️

Deleting a variable set doesn't automatically remove it from catalog items. The io_set_item junction records remain, causing broken references until manually cleaned up.

  • The type field distinguishes regular variable sets from container variable sets, but this distinction affects form rendering in non-obvious ways
  • Variable sets inherit security from their containing application scope, which can block cross-scope reuse even when the set is marked as global
⚠️

The title field is not automatically unique. You can create multiple variable sets with identical titles, leading to confusion in the catalog item configuration interface.

  • Performance degrades when variable sets contain many conditional variables because each condition is evaluated during form load — avoid deeply nested variable dependencies
Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

Related Tables

The most critical relationship is with item_option_new, which stores the individual variables that belong to variable sets. When you query variable sets, you'll almost always need to join to this table to get the actual variable definitions. The variable_set field on item_option_new references the sys_id of variable sets.

The io_set_item junction table links variable sets to catalog items (sc_cat_item) and record producers (sc_cat_item_producer). This many-to-many relationship means one variable set can be used by dozens of catalog items, and one catalog item can use multiple variable sets. You'll frequently need three-way joins across these tables to understand complete catalog item configurations.

When working with submitted requests, you'll also query sc_req_item alongside variable sets to understand which variable values were submitted. The connection flows through sc_item_option_mtom which stores the actual submitted variable values linked back to their variable definitions and parent variable sets.