Scripts

  • Release version: Zurich
  • Updated November 11, 2025
  • 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

    Scripting in ServiceNow CPQ extends configuration capabilities beyond simple rules, enabling administrators to model advanced logic for complex calculations, condition evaluations, and dynamic product data manipulation. Scripts are used selectively to complement declarative options such as standard rules and picklist extensions, ensuring flexibility without compromising maintainability.

    Show full answer Show less

    Where Scripts Run and Their Purpose

    • Rule conditions: Return a Boolean (true/false) to determine whether specific actions execute.
    • Rule actions: Modify field values, control element visibility, or dynamically build product lists.
    • Blueprint enrichments: Initialize or enrich configuration data during configuration events, including calling external systems or validating inputs.

    Expected Return Values

    Each script type requires specific return formats for predictable behavior:

    • Advanced condition: Boolean (true/false)
    • Advanced hiding: String (field name to hide)
    • Field determination: Depends on field type (number, text, multi-select array)
    • Inclusion/exclusion: Array of strings
    • Product action: ProductList object for BOM modifications
    • Enrichment: Updated configuration object

    Configuration Objects

    Scripts interact with key objects to read or modify data:

    • cfg: Read-only snapshot of current field values.
    • cfgRequest: Writable object in enrichments; use .set() to update fields.
    • ProductList: Used to add or modify bill of materials items.

    You can reference fields using dot or bracket notation (e.g., cfgRequest.fieldName or cfgRequest["fieldName"]).

    Working with External Data

    Scripts can leverage external data sources to create dynamic, maintainable configurations:

    • Query managed tables with lookup() to populate fields or product lists.
    • Integrate with external connections (e.g., Salesforce SOQL) during enrichments to retrieve data dynamically.

    This approach minimizes hard-coded logic and centralizes data management.

    Debugging and Testing

    The scripting interface offers tools to streamline development:

    • Code suggestions and autocomplete for functions, variables, and fields.
    • Help panel with supported functions, parameters, and examples.
    • Debugger supporting JSON input, output display, and console logs.
    • Ability to save common test inputs as comments for reuse.

    Best Practices

    • Favor declarative rules before resorting to scripts.
    • Keep scripts concise and focused on a single responsibility.
    • Always return the expected data types to ensure consistency.
    • Use clear, descriptive variable names and comments for maintainability.
    • Avoid complex nested conditionals; prefer tables or external data where possible.

    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.

    Best practices

    • 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.