--- sourceDocument: Australia Sales and Order Management sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/de-DE/order-management Release : - australia ft:locale : - de-DE ft:publication_title : - Australia Sales and Order Management ft:clusterId : - omgmt bundleId : - omgmt workflow : - Customer and Industry --- # Debugging in CPQ # Debugging in CPQ {#ariaid-title1} * Freigeben Version: Australia * * Aktualisiert 12. März 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 Minuten Lesedauer How to use the debugger to perfect your scripts before deployment. When you need to fix a script in CPQ, the debugging tool in Advanced Functions and Enrichment Scripts can help. This guide shows you how to write debug JSONs to isolate and test your scripts before deployment. By following these best practices for debugging faulty scripts, you can help ensure your blueprints run flawlessly. ## General guidelines for debugging {#rules-enrichments-debugging_in_logik_io__best_practices_for_debugging} Using `console.log()`: When coding a complex behavior, you may have to check whether certain values are set or manipulated the correct way. Instead of seeing only what is returned by the rule, use the `console.log([variableName])` function in a script to show the value of the variable at that line when run in the debugger. Comment out blocks of codes: When a script becomes long, it may be necessary to comment large sections of code to see where the behavior originates. This can usually be done by using `//` or `/* */` and then debugging. Comment out debug JSON for future use: If you are continually updating a rule during implementation, itʼs a good idea to save your debugging JSON either at the top or bottom of the script inside a comment block. That way, when the script is saved, the JSON can also be saved for future reference. For more tips on these features, see [Using comments and the console to debug scripts](https://servicenow-prod.fluidtopics.net/FZny1PXRXf2Z8BOEAPDDhg "Learn how comments and the console can help you debug your scripts."). ## How to use the debugger {#rules-enrichments-debugging_in_logik_io__how_to_use_the_debugger} When in the script editor: * Toggle the dubugger options by clicking the bug icon (a). * Enter your JSON in the Debugger Inputs section (b), as it would appear when your rule runs during configuration. * Run your rule with the debugger inputs by clicking Run Debugger in the Debugger Output panel. Hinweis: The script does not have to be saved in order to run the debugger. The state of the script when the button is clicked is used when testing. * Returned objects and console.log information appear in the Debugger Output panel (d). {#rules-enrichments-debugging_in_logik_io__ul_olt_h23_5hc} The CPQ debugger uses JSON format, which is written using attribute-value pairs. The attributes are the variable names of the fields used in the rule, and the value is the fieldʼs data in its object format. Hinweis: As long as a field is referenced in the rule or enrichment, it must have a corresponding attribute in the JSON, or the script cannot be run in the debugger. Also note: * The JSON package is wrapped using curly brackets ({ }) * Each field is separated by a comma (,). * Each attribute-value pair is separated by a colon (:). {#rules-enrichments-debugging_in_logik_io__ul_rcw_s2g_dhc} The structure of the JSON you use depends on the object type of each field, as well as whether the script is being used for a rule or an enrichment. ## Field-specific JSON formatting {#rules-enrichments-debugging_in_logik_io__field-specific_json_formatting} * Text, numbers, Boolean values, and single-select picklists fields are the easiest fields to debug, as they correspond to simple, singular-value objects such as strings, numbers, and Boolean values. { "cfg":{ "textField": "value", "singleSelect picklist": "value", "numberField": 123, "booleanField": true } } * Date fields use the ISO-8601 international standard to hold date information. If a field inputs dates in the debugger, the data should be a string in the format `YYYY-MM-DDThh:mm:ss.sssZ`. { "cfg":{ "dateField": "2024-01-01T00:00:00.000Z" } } * Multi-select picklists are in the form of an array that contains strings. Even with only one option selected, the strings should be in an array format when debugging, wrapped by square braces (\[ \]) and separated by commas (,). { "cfg":{ "multiSelect picklist": [ "option 1", "option 2" ] } } * Product pickers are unique to reference in a rule or enrichment, since they have their own type of simple rules, bulk actions. They can be referenced only by their picklist option, treating them as a single-select or multi-select field. Or, the debugger can reference a product picker subfield or aggregate using the key `pkr`. { "cfg": { "productPickerSS": "selectedValue", "productPickerMS": [ "selectedValue1", "selectedValue2" ] }, "pkr": { "productPicker2": { "value": "productPicker2_option1", "select": true, "quantity": 100, "exampleSubfield": "Example Value", "aggregates": { "quantity_max": 100 } } } } Note that when you reference a product picker subfield in a rule, you need to use the `pkr` object and not `cfg`. let x = pkr.productPickerName.subFieldName * Sets cannot be referenced by advanced functions, but the fields contained in them can. Due to the nature of the set field, a setʼs rows can be determined and referenced only in the On Configure/Reconfigure enrichment. However, you can test for when a field such as optionValue is in a rule. { "set": { "exampleSet": { "index": 1, "optionValue": "product1", "selectOption": true, "size": 2, "aggregateExample1": 1 } } } To learn more about defaulting a setʼs fields, see [Scripting: How to populate set values](https://servicenow-prod.fluidtopics.net/w9K0XeOpjW_6ft26VqPDTQ "View a detailed example of how to use an On Configure/Reconfigure blueprint enrichment script to load field values into a set."). {#rules-enrichments-debugging_in_logik_io__ul_pss_hwz_4hc} ## Context-specific JSON formatting {#rules-enrichments-debugging_in_logik_io__context-specific_json_formatting} Field inputs are entered in JSON format, using the field variable name as the key and the intended value as the value. { "cfg": { "exampleField": "Example Value" } } On configuration and reconfiguration, inputs are entered in JSON format, using the field variable name as the key. The value is an object consisting of two properties: value and userEdited. value should be set to the intended field value. userEdited is a Boolean value. ## Context-specific JSON formatting: fields {#rules-enrichments-debugging_in_logik_io__section_jlw_wwz_4hc} { "cfgRequest": { "exampleField": { "value": "Example Value", "userEdited": false }, "exampleMultiselect picklist": { "value": [ "one", "two" ], "userEdited": false } } } For more information about how to use the userEdited property, see [Scripting: Checking for first and subsequent configurations](https://servicenow-prod.fluidtopics.net/bqFAdC4MeH52Qe~678BnmQ "You can test whether a configuration is being initialized or being reconfigured, and set code to execute based on the result.") ## Context-specific JSON formatting: product pickers {#rules-enrichments-debugging_in_logik_io__section_jhb_mxz_4hc} "cfgRequest": { "pkr": { "productPicker1": { "data": [ { "value": { "value": "productPicker1_option1", "userEdited": false }, "select": { "value": true, "userEdited": false }, "quantity": { "value": 100, "userEdited": false }, "exampleSubfield": { "value": "Example Value", "userEdited": false } } ], "aggregates": { "quantity_max": { "value": 100 } } } }, "productPicker2": { "value": "productPicker2_option1", "userEdited": false } } } ## Context-specific JSON formatting: sets {#rules-enrichments-debugging_in_logik_io__section_bkz_mxz_4hc} { "cfgRequest": { "set": { "exampleSet": { "data": [ { "index": { "value": 1 }, "optionValue": { "value": "product1", "userEdited": false }, "selectOption": { "value": true, "userEdited": false }, "textField": { "value": "a", "userEdited": false } } ], "size": { "value": 1, "userEdited": false }, "aggregateExample1": { "value": 1 } } } } } ## Context-specific JSON formatting: product pickers in sets {#rules-enrichments-debugging_in_logik_io__section_rtt_nxz_4hc} "cfgRequest": { "set": { "exampleSet": { "data": [ { "index": { "value": 1 }, "optionValue": { "value": "product1", "userEdited": false }, "selectOption": { "value": true, "userEdited": false }, "productPicker1InSet": { "value": [ "option1_Of_productPicker1InSet", "option2_Of_productPicker1InSet" ], "userEdited": false }, "pkr": { "productPicker2InSet": { "data": [ { "value": { "value": "option1_Of_productPicker2InSet", "userEdited": false }, "select": { "value": true, "userEdited": false }, "quantity": { "value": 100, "userEdited": false } } ], "aggregates": { "quantity_max": { "value": 100 } } } } } ], "size": { "value": 1, "userEdited": false }, "aggregateExample1": { "value": 1 } } } } } On BOM Response enrichment: Product List: Inputs are entered as an array of objects in JSON format, using the property variable name as the key, and the intended value as the value. [ { "id": "test product", "quantity": 2 }, { "id": "test product2", "quantity": 5, "bomType": "MANUFACTURING" } ] Picklist extension Pricing enrichment: picklist extension Request: Inputs are entered as an array of objects in JSON format, using the property variable name as the key, and the intended value as the value. In the example, "set" and "index" are only needed if using a set. [ { "fieldVariableName": "myField1", "set": "mySetVariableName1", "index": 1, "optionValue": "Option 1", "productId": "myProduct1", "productUniqueIdentifier": "myId" } ] ## If the debuggerʼs behavior is different from runtime behavior {#rules-enrichments-debugging_in_logik_io__section_mw5_sjg_dhc} In almost every case, the debugging JSON needs to match exactly what would normally be entered during runtime as valid values for the fields. Make sure that you are using the correct data type or structures described above. In other cases, similar rules may be acting on the same field. In this case, the debugger will not be helpful, as it can only show the behavior of one rule at a time. It might be necessary to inactivate entire rules and redeploy in order to rule out the undesired behavior. If all else fails, please open a case with our support team, or email us at support@logik.io.