Scripts
Summarize
Summary of Scripts
Scripting in CPQ (Configure, Price, Quote) enables advanced configuration logic beyond simple declarative rules. It allows administrators to dynamically calculate values, evaluate conditions, and manipulate product data for complex scenarios. Scripts are used within rule conditions, rule actions, and blueprint enrichments to enhance flexibility during configuration, validation, and pricing processes.
Show less
While scripting offers powerful customization, it is intended to complement—not replace—declarative options such as standard rules and product pickers. Scripts should be reserved for specialized cases where simpler methods are insufficient.
Where to Use Scripts
- Rule Conditions: Scripts return a Boolean (true/false) to control whether an action executes.
- Rule Actions: Scripts set field values, show/hide elements, or dynamically build product lists.
- Blueprint Enrichments: Scripts initialize data, interact with external systems, or enhance configurations during “On Configure” or “Reconfigure” events.
Expected Return Values and Configuration Objects
Each script type requires a specific return format to ensure predictable results, such as Boolean for conditions, strings for hiding fields, arrays for inclusion/exclusion, and ProductList objects for product actions.
Scripts interact with several configuration objects:
- cfg: A read-only snapshot of current field values for use in rules.
- cfgRequest: A writable object used in enrichments to modify field values dynamically.
- ProductList: Manages items in the bill of materials (BOM), allowing addition or modification of products.
Properties can be accessed using dot or bracket notation (e.g., cfgRequest.fieldName or cfgRequest["fieldName"]).
Working with External Data
Scripting supports incorporating external data to create dynamic configurations:
- Managed Tables: Use
lookup()to query data and map results into fields or product lists. - External Connections: Make approved calls (e.g., SOQL queries to Salesforce) within enrichments to populate sets or field values.
These approaches reduce hardcoding and centralize data management for easier maintenance.
Debugging and Testing
The scripting interface offers built-in tools to support development:
- Code Suggestions: Autocomplete for functions, variables, and fields.
- Help Panel: Documentation of supported functions and parameters with examples.
- Debugger: Accepts JSON input and displays script output and console logs, enabling thorough testing.
- Ability to save common test inputs as comments for reuse.
Best Practices
- Prefer declarative rules whenever possible to maintain simplicity.
- Keep scripts concise and focused on a single task.
- Always return the expected data type for each script context.
- Use clear variable names and add comments for maintainability.
- Avoid complex nested or lengthy conditional logic; use tables or external data sources instead.
Learn 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.
Scripting 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.
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
trueorfalseto 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
| 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 → |
| 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.