Get a catalog variable value from an RITM

Catalog variables are not database columns — they're virtual properties that ServiceNow constructs on demand from the sc_item_option_mtom table. The current.variables.variable_name syntax is ServiceNow's magic that hides the complexity of joining to the options table. Most developers try to query variables like regular fields and wonder why their addQuery() calls fail — variables only work through the dot-notation API on loaded records.

When to use this

• In Business Rules on sc_req_item when you need catalog form data to drive workflow logic
• In Script Includes processing single RITM records where you have a loaded GlideRecord instance
• In scheduled jobs that process small batches of requests where variable values affect processing
• When validating or transforming catalog input before creating related records

When NOT to use this

• Don't use this in client scripts — variables aren't available client-side, use g_form.getValue() on catalog forms instead
• Don't use this in loops over multiple RITMs — each variable access triggers queries, use sc_item_option_mtom joins for bulk operations
• Don't use this on sc_request records — variables belong to items, not requests
• Don't use this in reporting — variables aren't indexed and will kill performance on large datasets

Key behaviors and gotchas

• Variables only exist on sc_req_item records, not sc_request — check your table context first
• Reference variables return sys_ids with getValue() but human names with getDisplayValue() — choose based on what you need
• Boolean variables return string 'true' or 'false' not JavaScript booleans — use string comparison
• Multi-choice variables return comma-separated strings — split on commas to get individual values
• Accessing non-existent variables throws script errors — use hasOwnProperty() or try/catch for safety
• Variable names in code must match the exact name field on the variable record, not the question text