---
sourceDocument: Australia Sales Customer Relationship Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/order-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Sales Customer Relationship Management

ft:clusterId :

    - omgmt

bundleId :

    - omgmt

workflow :

    - Customer and Industry


---

# Scripting: Checking for first and subsequent configurations

# Scripting: Checking for first and subsequent configurations {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 Scripting: Checking for first and subsequent configurations

This guidance explains how to distinguish between the initialization and reconfiguration phases of a configurable product within ServiceNow CPQ scripting.
This distinction allows you to control when certain scripts execute---either only during the first configuration setup or during subsequent edits---enabling more precise and user-friendly configuration behaviors.
Show full answer Show less  

## Key Methods to Detect Initialization vs. Reconfiguration

* **Using `userEdited` Property:** Each field in the configuration has a Boolean `userEdited` property indicating whether the end user has modified the field. During initialization, this is `false` for all fields, while during reconfiguration, it reflects user changes. Scripts can check `userEdited == false` to assign default values only if the user has not modified the field.
* **Checking the `lineId` Partner Field:** When integrated with Salesforce, the `lineId` partner field is empty during initial configuration but populated during reconfiguration. Scripts can use this field to run code exclusively during initialization (`lineId.value == null`) or reconfiguration (`lineId.value != null`). Including `return cfgRequest;` after these checks ensures subsequent code does not execute erroneously.
* **Creating and Using an `isInitial` Text Field:** For environments without Salesforce integration, you can create a custom text field named `isInitial` linked to your blueprint. This field starts blank on initialization and toggles between "Yes" and "No" on subsequent reconfigurations through script logic. This approach immediately detects re-entry into the configurator without needing to save the entire quote line editor in Salesforce. It also allows referencing `isInitial` in rule conditions for flexible behavior control beyond the enrichment script.

## Practical Benefits and Considerations

These scripting techniques allow you to:

* Set default values only when a configuration is first created, preserving user input during reconfigurations.
* Implement unique behaviors depending on whether the user is initializing or editing a configuration.
* Integrate seamlessly with Salesforce data when available or use standalone methods otherwise.
* Leverage custom fields to extend configurator logic and rule conditions without impacting user experience negatively.

While these methods enable powerful flexibility, it is recommended to minimize behavioral differences between initialization and reconfiguration to maintain a consistent and intuitive experience for your end users.  
You can test whether a configuration is being initialized or being reconfigured, and set code to execute based on the result.

Sometimes it is necessary to execute code only when the configuration is being initialized, or only when it is being reconfigured. For example, you might want to set a field to its default values at the beginning of a
configuration, but keep the userʼs selection during any future edit.

The methods below can be combined without interfering with one another and can lead to flexible and unique code behaviors for your configurable products.

## userEdited: running only when a field was not edited {#enrichments_on_configurer_and_reconfigure_behavior__section_hbg_vrr_4hc}

Two field properties can be accessed in the On Configure/Reconfigure enrichment: value and userEdited. While the value property holds the data contained in
the field and is usually what will be accessed when scripting, userEdited contains a Boolean value that stores whether the field has been changed by the end user.

This can be used in if statements to write a default value only when the field has not been changed by the user. For example:

    if (cfgRequest.[fieldVariableName].userEdited == false) {
          //code to run
    }

All fields will have the userEdited property set to false when the configuration is initialized, but when reconfiguring, some will be set to true based on the changes made by the user. If youʼd like a behavior to occur
only when a field has or hasnʼt been edited, write the code to execute after one of these checks.

## The lineId partner field {#enrichments_on_configurer_and_reconfigure_behavior__section_gnt_wrr_4hc}

Alternatively, if youʼd like to make only one check in the On Configure/Reconfigure enrichment script, and have Salesforce integration, the lineId partner field will only be populated with the
Salesforce ID of the parent configurable productʼs quote line when reconfiguring. It will not be populated when a configuration is initialized.

This is because when a CPQ configuration is initialized, this ID does not yet exist, because the configuration has yet to be saved. Only after a CPQ configuration has been created and the quote line editor saved are any quote lines created in Salesforce. So, when we see that the lineId partner field is present, we
can be sure that the current session is due to a reconfiguration, not a new configuration.

Script writers can take advantage of this distinction by putting any code that must be run only on initialization or reconfiguration under a check for this value.

Here is how the field can be referenced in the On Configure/Reconfigure enrichment:

    cfgRequest.partner.quote.lineId.value;

If the behavior should only happen when the configuration is initialized, you could add the following check:

    if (cfgRequest.partner.quote.lineId.value == null) {
          //code to run
          return cfgRequest;
    }

Adding the `return cfgRequest;` line in the check guarantees that any code after the check for the line ID will not be executed.

Similarly, if the behavior should happen only when the configuration is reconfigured, add the inverse check:

    if (cfgRequest.partner.quote.lineId.value != null) {      
          //code to run
          return cfgRequest;
    }

For more information on partner fields, see [CPQ fields, system fields, and partner fields](https://www.servicenow.com/docs/GFBhxHszhmerpGvq1Vxh4g "Learn about the three types of fields in CPQ—CPQ, system fields, and partner fields. Understand how each type stores, retrieves, and displays data in configurations, and how they interact with Salesforce and partner systems for seamless data integration.").

## isInitial: creating a text field {#enrichments_on_configurer_and_reconfigure_behavior__section_yq5_xrr_4hc}

Another way to guarantee that a distinction is present (regardless of whether Salesforce is used as an entry point into the configurator) is to create a field that checks whether the current configuration is due to an
initialization or a reconfiguration.

Create a text field with the variable name `isInitial`. Associate the field with your blueprint. Then, in the On Configure/Reconfigure enrichment, add the following lines:

    if (cfgRequest.isInitial.value === "Yes" || cfgRequest.isInitial.value === "No") {
          cfgRequest.isInitial.set("value","No");
    }
    else
    {
    c fgRequest.isInitial.set("value","Yes");
    }

On initialization, the `isInitial` field will be blank. Therefore, the script will set the value of `isInitial` to Yes in the `else` clause.

On the first reconfiguration, `isInitial` will be Yes. Therefore, the script will set the value of `isInitial` to No in the `if` clause.

On every subsequent reconfiguration, `isInitial` will be No, and will remain No.

This method has the added benefit of not having to save the entire QLE in SFDC in order to make the distinction between an initialization or reconfiguration. The method immediately detects when the
user enters the configurator a second time.

This method also includes the ability to reference the new field as a condition in rules, such as making a rule fire specifically on initialization or reconfiguration. It does not require the behavior to exist only in
the On Configure/Reconfigure script. However, to keep the configuring experience similar from the end user's perspective, you should be wary of making too many behavioral differences between initialization and
reconfiguration.