{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":37888,"path":"order-management/scripts.md","title":"Scripts","bundle":null,"doc_type":null,"release":"australia","body":"\n# Scripts\n\nLearn how scripting extends CPQ beyond simple rules—understand where scripts run, what they return, and how to use them to model advanced configuration logic safely and efficiently.\n\nScripting enhances 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.\n\nScripting complements, but does not replace, declarative options. Use standard rules, picklist extensions, and product pickers first. Reserve scripting for specialized scenarios.\n\n## Where can you use scripts\n\n-   Rule conditions: Return `true` or `false` to determine whether actions run.\n-   Rule actions: Set field values, hide or display elements, or build product lists dynamically.\n-   Blueprint enrichments: Initialize data, call external systems, or enrich configurations during “On Configure” or “Reconfigure” events.\n\nEach script type requires a specific return value to ensure predictable results.\n\n## Expected return values\n\n<table id=\"table_iry_dsy_ghc\"><thead><tr><th>\n\nScript Type\n\n</th><th>\n\nReturn Format\n\n</th><th>\n\nExample\n\n</th></tr></thead><tbody><tr><td>\n\nAdvanced condition\n\n</td><td>\n\nBoolean\n\n</td><td>\n\n`true` or `false`\n\n</td></tr><tr><td>\n\nAdvanced hiding\n\n</td><td>\n\nString\n\n</td><td>\n\n`\"field_to_hide\"`\n\n</td></tr><tr><td>\n\nField determination\n\n</td><td>\n\nDepends on field type\n\n</td><td>\n\nNumber → `5`; Text → `\"Red\"`; Multi-select → ```\n[\"Option1\",\n              \"Option2\"]\n```\n\n</td></tr><tr><td>\n\nInclusion and exclusion\n\n</td><td>\n\nArray\n\n</td><td>\n\n`[\"OptionA\", \"OptionB\"]`\n\n</td></tr><tr><td>\n\nProduct action\n\n</td><td>\n\nProductList object\n\n</td><td>\n\n`ProductList.add({id:\"123\", qty:2})`\n\n</td></tr><tr><td>\n\nEnrichment\n\n</td><td>\n\nUpdated configuration object\n\n</td><td>\n\n`return cfgRequest;`\n\n</td></tr></tbody>\n</table>## Configuration objects\n\nScripts interact with the following configuration objects:\n\n-   `cfg`: A read-only snapshot of current field values used by rules.\n-   `cfgRequest`: A writable object available in Enrichments; use `.set(\"value\", x)` to modify fields.\n-   `ProductList`: Used to add or modify items in the bill of materials \\(BOM\\).\n\nYou can reference properties using either dot or bracket notation \\(`cfgRequest.fieldName` or `cfgRequest[\"fieldName\"]`\\).\n\n## Working with external data\n\nUse external data to enhance configurations dynamically:\n\n-   Managed tables: Query data with `lookup()` to map results into fields or products.\n-   External connections: Make approved calls \\(for example, SOQL queries to Salesforce\\) to populate sets or field values in Enrichments.\n\nThese techniques reduce hard-coded logic and centralize data management.\n\n## Debugging and testing\n\nThe scripting interface includes built-in tools:\n\n-   Code suggestions: Autocomplete for functions, variables, and fields.\n-   Help panel: Lists all supported functions and parameters with examples.\n-   Debugger: Accepts JSON input and displays output and `console.log()` results. Save common test inputs as comments for reuse.\n\n## General guidelines\n\n-   Prefer declarative rules when possible.\n-   Keep scripts concise and focused on a single task.\n-   Always return the expected data type.\n-   Use clear variable names and comments.\n-   Avoid nested or long conditional logic—use tables or external connections instead.\n\n**Related topics**  \n\n\n[Create scripts](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/australia/order-management/scripting.md)\n\n"}}