sc_item_option Table — ServiceNow Reference

Table Reference/sc_item_option

The sc_item_option table stores variable values submitted with catalog item orders in the Service Catalog module. Each record represents a single question response linked to an sc_req_item record. Developers must join through request_item to access the parent RITM data.

What This Table Is

The sc_item_option table captures every variable response submitted when users order catalog items. When a user fills out a catalog form and clicks Order Now, ServiceNow creates one record here for each question they answered. This includes everything from simple text fields to complex reference selectors and multi-choice questions.

Owned by the Service Catalog module, this table serves as the bridge between user input and fulfillment automation. Business Rules, workflows, and Flow Designer actions query these records to customize approvals, generate configuration items, provision accounts, or calculate pricing. The data here drives the entire catalog fulfillment process from order submission through delivery.

This table doesn't extend task or any standard table—it's a standalone catalog-specific structure. Each record links to sc_req_item through the request_item reference field, creating a one-to-many relationship where one RITM can have dozens of variable responses.

In large enterprises, expect 50-200 records per catalog item order, with millions of total records over time. The table performs well for single-RITM queries but can strain when aggregating across thousands of requests without proper indexing on request_item and item_option_new fields.

When You'll Script Against This Table

You'll primarily script against sc_item_option in Business Rules on sc_req_item, catalog workflows, and Flow Designer actions triggered by RITM state changes. Script Includes that handle catalog automation frequently query this table to extract user responses and transform them into API calls or CI attributes. Scheduled Jobs also access these records for reporting and cleanup of old catalog data.

The catalog role provides read access, while catalog_admin allows full CRUD operations. Custom applications scoped to Service Catalog can access these records, but third-party scoped apps may need explicit table access configuration.

Common scripting patterns:

Extract variable values to populate CI fields during provisioning
Build dynamic approval conditions based on requested quantities or configurations
Calculate total costs by aggregating pricing variables across line items
Generate API payloads for external systems using user-provided configuration data
Create follow-up tasks with descriptions built from catalog form responses
Validate business rules against submitted data before moving to fulfillment
Report on catalog usage patterns by analyzing popular variable combinations

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.

Table Gotchas

⚠️

The display_value field shows what users see, but value contains the actual stored data. For reference fields, value holds the sys_id while display_value shows the display name. Always use value for queries and comparisons.

⚠️

Records persist even after RITM deletion due to referential integrity settings. Always check if the parent request_item still exists before processing these records in scheduled jobs or bulk operations.

The item_option_new field links to item_option_new table, not catalog variables directly—you need to traverse through this relationship to get variable metadata
Multi-choice questions create multiple records with the same item_option_new but different values—don't assume one variable equals one record

⚠️

Querying without request_item filtering will scan the entire table. Always include request_item in your GlideRecord queries to hit the proper index and avoid performance issues.

The order field controls display sequence but isn't reliable for programmatic sorting—use sys_created_on instead
Large text responses get truncated in list views but the full content exists in the database—use getValue() to retrieve complete values

The primary relationship connects to sc_req_item through the request_item reference field. This relationship is essential—you'll almost never query sc_item_option in isolation since the variable values only make sense in context of their parent RITM. The item_option_new table provides variable metadata including names, types, and configuration details.

Through sc_req_item, you'll frequently join to sc_request for cart-level information and sys_user for requestor details. The sc_cat_item table becomes relevant when you need to understand which catalog item generated these variable responses. For automated fulfillment, you'll often cross-reference cmdb_ci when populating configuration items with user-provided data.

Developers building catalog integrations commonly query this table alongside wf_context to track workflow variables and sc_task when catalog fulfillment requires manual tasks. The combination provides complete visibility into order submission, variable capture, workflow processing, and task execution.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
request_item	reference	Request Item	Links to sc_req_item parent record. This field is indexed and should be included in every query for performance.
item_option_new	reference	Item Option	References the variable definition in item_option_new table. Use this to get variable names, types, and configuration details.
value	string	Value	The actual submitted value. For reference variables, contains sys_id. For choice lists, contains the choice value, not the label.
display_value	string	Display Value	User-friendly display of the value. Shows display names for references and choice labels. Never use for queries or comparisons.
order	integer	Order	Display sequence from the catalog form. Not reliable for sorting—gaps and duplicates exist when variables are reordered.
mandatory	boolean	Mandatory	Indicates if the variable was required when submitted. Useful for validation logic but doesn't guarantee value exists.
visible	boolean	Visible	Whether the variable was visible to the user during submission. Hidden variables still create records with default values.
sc_item_option	reference	Catalog Item Option	Self-referencing field used for variable dependencies and conditional logic. Links child variables to their parent conditions.
no_export	boolean	No Export	Excludes sensitive variables from exports and integrations. Check this before sending data to external systems.

Common Queries

Get all variable responses for a specific RITM

var gr = new GlideRecord('sc_item_option');
gr.addQuery('request_item', current.sys_id);
gr.orderBy('order');
gr.query();
while (gr.next()) {
    // Process each variable response
    gs.info('Variable: ' + gr.item_option_new.name + ', Value: ' + gr.value);
}

Find specific variable value for approval routing

var gr = new GlideRecord('sc_item_option');
gr.addQuery('request_item', current.sys_id);
gr.addQuery('item_option_new.name', 'business_justification');
gr.query();
if (gr.next()) {
    // Route based on justification content
    var justification = gr.getValue('value');
    return justification.toLowerCase().indexOf('urgent') > -1;
}
return false;

Build CI attributes from catalog variables for provisioning

var ciAttributes = {};
var gr = new GlideRecord('sc_item_option');
gr.addQuery('request_item', ritm_sys_id);
gr.addQuery('item_option_new.map_to_field', '!=', '');
gr.query();
while (gr.next()) {
    // Map catalog variables to CI fields
    var fieldName = gr.item_option_new.map_to_field.toString();
    ciAttributes[fieldName] = gr.getValue('value');
}
return ciAttributes;

Count catalog items by variable selection

var ga = new GlideAggregate('sc_item_option');
ga.addQuery('item_option_new.name', 'operating_system');
ga.addQuery('request_item.state', 'IN', '2,3'); // Approved states
ga.groupBy('value');
ga.addAggregate('COUNT');
ga.query();
while (ga.next()) {
    var os = ga.getValue('value');
    var count = ga.getAggregate('COUNT');
    gs.info(os + ': ' + count + ' requests');
}

Wrong way vs right way to query variable values

// WRONG: Querying by display_value fails for references
var wrong = new GlideRecord('sc_item_option');
wrong.addQuery('display_value', 'John Doe'); // This won't work reliably

// RIGHT: Query by value field and traverse references
var right = new GlideRecord('sc_item_option');
right.addQuery('request_item', current.sys_id);
right.addQuery('item_option_new.name', 'requested_for');
right.query();
if (right.next()) {
    var userId = right.getValue('value'); // Gets the sys_id
    var user = new GlideRecord('sys_user');
    if (user.get(userId)) {
        gs.info('User: ' + user.name);
    }
}

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sc_item_option