Scripts

  • Release version: Australia
  • Updated March 12, 2026
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Scripts in ServiceNow CPQ

    Scripting in ServiceNow CPQ extends configuration capabilities beyond simple declarative rules by enabling advanced, dynamic logic for complex scenarios. It allows administrators to calculate values, evaluate conditions, and manipulate product data in real time. Scripts are particularly useful when standard rules, picklist extensions, and product pickers cannot fully address the required configuration logic.

    Show full answer Show less

    Where to Use Scripts

    • Rule conditions: Scripts return boolean values (true/false) to control when specific actions execute.
    • Rule actions: Scripts dynamically set field values, control UI element visibility, or build product lists.
    • Blueprint enrichments: Scripts run during configuration events ("On Configure" or "Reconfigure") to initialize data, validate inputs, enrich configurations, or integrate external systems.

    Expected Return Values and Configuration Objects

    Each script type requires specific return formats to ensure predictable behavior. Common return formats include boolean values, strings, arrays, numbers, or complex objects like ProductList. Key configuration objects available to scripts include:

    • cfg: Read-only snapshot of current field values for rule evaluation.
    • cfgRequest: Writable object used in enrichments to modify configuration fields.
    • ProductList: Used to add or modify items in the bill of materials (BOM).

    Scripts can access these objects using dot or bracket notation for flexible data manipulation.

    Working with External Data

    Scripts can leverage external data sources to enhance configurations dynamically, reducing hard-coded logic and improving maintainability:

    • Managed tables: Use the lookup() function to query data and map results into configuration fields or products.
    • External connections: Approved integrations (e.g., Salesforce SOQL queries) can populate fields or product sets during enrichments.

    Debugging and Best Practices

    The scripting interface provides robust tools to assist development and testing:

    • Code suggestions: Autocomplete for functions, variables, and fields.
    • Help panel: Documentation of supported functions with examples.
    • Debugger: Allows JSON input testing and displays outputs with console.log() support.

    Best practices for scripting include:

    • Prefer declarative rules whenever possible for simplicity and maintainability.
    • Keep scripts concise and focused on a single responsibility.
    • Always return the expected data type for the script context.
    • Use clear variable names and add comments for readability.
    • Avoid complex nested conditionals; use tables or external data sources instead.

    Learn how scripting extends ServiceNow CPQ beyond simple rules—understand where scripts run, what they return, and how to use them to model advanced configuration logic safely and efficiently.

    Scripting enhances ServiceNow CPQ when configuration logic requires more flexibility than simple rules. Administrators can use scripts to calculate complex values, evaluate conditions, or manipulate product data dynamically. Scripts are available in rule conditions, actions, and in blueprint enrichments for initialization, validation, or pricing.

    Scripting complements, but does not replace, declarative options. Use standard rules, picklist extensions, and product pickers first. Reserve scripting for specialized scenarios.

    Where can you use scripts

    • Rule conditions: Return true or false to determine whether actions run.
    • Rule actions: Set field values, hide or display elements, or build product lists dynamically.
    • Blueprint enrichments: Initialize data, call external systems, or enrich configurations during “On Configure” or “Reconfigure” events.

    Each script type requires a specific return value to ensure predictable results.

    Expected return values

    Table 1. Expected return values
    Script Type Return Format Example
    Advanced condition Boolean true or false
    Advanced hiding String "field_to_hide"
    Field determination Depends on field type Number → 5; Text → "Red"; Multi-select → 
    ["Option1",
              "Option2"]
    Inclusion and exclusion Array ["OptionA", "OptionB"]
    Product action ProductList object ProductList.add({id:"123", qty:2})
    Enrichment Updated configuration object return cfgRequest;

    Configuration objects

    Scripts interact with the following configuration objects:

    • cfg: A read-only snapshot of current field values used by rules.
    • cfgRequest: A writable object available in Enrichments; use .set("value", x) to modify fields.
    • ProductList: Used to add or modify items in the bill of materials (BOM).

    You can reference properties using either dot or bracket notation (cfgRequest.fieldName or cfgRequest["fieldName"]).

    Working with external data

    Use external data to enhance configurations dynamically:

    • Managed tables: Query data with lookup() to map results into fields or products.
    • External connections: Make approved calls (for example, SOQL queries to Salesforce) to populate sets or field values in Enrichments.

    These techniques reduce hard-coded logic and centralize data management.

    Debugging and testing

    The scripting interface includes built-in tools:

    • Code suggestions: Autocomplete for functions, variables, and fields.
    • Help panel: Lists all supported functions and parameters with examples.
    • Debugger: Accepts JSON input and displays output and console.log() results. Save common test inputs as comments for reuse.

    General guidelines

    • Prefer declarative rules when possible.
    • Keep scripts concise and focused on a single task.
    • Always return the expected data type.
    • Use clear variable names and comments.
    • Avoid nested or long conditional logic—use tables or external connections instead.