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


---

# CPQ fields, system fields, and partner fields

# CPQ fields, system fields, and partner fields {#ariaid-title1}

* Freigeben Version: Australia
* 
* Aktualisiert 12. März 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 Minuten Lesedauer

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.

There are three categories of fields in the CPQ environment: CPQ fields, system fields, and partner fields.

## CPQ fields {#system_fields_vs_partner_fields__logik_fields}

A CPQ field is a user-defined field that is custom to the CPQ environment. Its type can be number, text, picklist, set, or product picker. When users create fields in CPQ, they can manually assign default values in the field definition, or they can set values through
determination actions.

The following example shows how a user would set a CPQ field in an On Configure/Reconfigure enrichment:

    cfgRequest.testField.set("value", "Hello World"); 

For a more complete description of CPQ fields, see [Configure fields](https://servicenow-prod.fluidtopics.net/oOs55ePFJIhxoE4qG9076g "Learn about how fields in CPQ help structure data collection efficiently and about the various types of field. Associate fields with blueprints for consistent use across configurations, layouts, and rules.").  
Hinweis:  
In organizations that do not use Salesforce for their launch-point into CPQ, all fields must be initialized in their API call.

## System fields {#system_fields_vs_partner_fields__system_fields}


System fields are predefined. System fields cannot be assigned a default value because they leverage the SFDC product cache (or the current date and time) to generate their values.

The following example shows how a user would call a system field in an On Configure/Reconfigure enrichment:

    let pC = {"input2":cfgRequest.sys.productCode.value};

System fields can be added directly to any layout. There are no issues with displaying them regardless of whether they contain predefined data.

In the layout editor:


In the Configurator UI:

Unit of Measure is blank because in this example, it has not been defined in SFDC.

The mapping of each of these system fields to their respective SFDC object is as follows. The field API name is in parentheses.

* sys.productUOM \> Product: Quantity Unit Of Measure (QuantityUnitOfMeasure)
* sys.productName \> Product: Product Name (Name)
* sys.productFamily \> Product: Product Family (Family)
* sys.productDescription \> Product: Product Description (Description)
* sys.productCode \> Product: Product Code (ProductCode)
* sys.enableValidation: value defaults to true
* sys.currentDate: Simple time API call, returns date of UTC
* sys.actionContext \> Quote Line: Action Context (LGK ActionContext c)
* sys.productPrice \> Price Book Entry: List Price (UnitPrice)
* sys.productId: value depends on Admin Settingssys.productId changes to whatever is defined in your CPQ environment settings. For instance, if the Product Id field was set to Product Code, the resulting data would be Product Code, making it identical to the sys.productCode field.

{#system_fields_vs_partner_fields__ul_lrh_x2f_dhc}


If the Product Id field was instead set to Partner Id, the data would be pulled from the SFDC field Product2 Id (ID as the field API name):


## Partner fields {#system_fields_vs_partner_fields__partner_fields}

Partner fields are fields that use a POST call to initialize a configuration via API. Partner fields leverage the partnerʼs data set to generate field values.

The mapping of each of these partner fields to their respective SFDC object is as follows. The field API name is in parentheses.

* partner.quote.id Quote \> Record ID (Id)
* partner.quote.lineId Quote Line \> Record ID (Id)
* partner.quote.pricebookId Quote \> Pricebook ID (SBQQPricebookIdc)
* partner.quote.currencyIsoCode Quote \> CurrencyIsoCodepartner.quote.currencyIsoCode defaults to USD if your organization does not have multi-currency enabled in their Salesforce Org. To enable multi-currency, follow the
  steps in this Salesforce article: [Enable Multiple Currencies](https://help.salesforce.com/s/articleView?id=sales.admin_enable_multicurrency.htm&type=5).

{#system_fields_vs_partner_fields__ul_kqy_2gf_dhc}

When using these fields, it's important to note that some of the data may not have any value (null) when the product is first configured. To make sure that there are no initialization errors, include null checks in any rules or
scripts that utilize partner fields.

These fields cannot be directly added to a layout like system fields can. Instead, you can use CPQ fields to populate the data in partner fields via an initialization enrichment.

The following example initialization enrichment populates the values of the partner fields into the configurator:

    let quoteId = cfgRequest.partner.quote.id.value;
    let lineID = cfgRequest.partner.quote.lineId.value;
    let currencyISO = cfgRequest.partner.quote.currencyIsoCode.value;
    let priceBookID = cfgRequest.partner.quote.pricebookId.value;

    if (quoteId != null) {
    	cfgRequest.quoteIDTest.set("value", quoteId);
    }
    if (lineID != null) {
    	cfgRequest.lineIDTest.set("value", lineID);
    }
    if (currencyISO != null) {
    	cfgRequest.currencyISOCodeTest.set("value", currencyISO);
    }
    if (priceBookID != null) {
    	cfgRequest.pricebookIDTest.set("value", priceBookID);
    }
    return cfgRequest;

Initial configuration:

Reconfiguration:

Line ID is now populated.

How you use partner and system fields is up to you. Some organizations find it helpful to display this information in the configurator to the end user, while others use it in the background in rules to drive pricing conditions.
**Zugehörige Konzepte**   

* [Grid-style fields and field collections](https://servicenow-prod.fluidtopics.net/_4Ru4DlNVy3XMbYgRwcv1g "Learn about the various types of grid-style fields: the picklist extension, the field grid, the indexed set, the associated picklist set, and the product picker. Learn how best to choose a field type for your data.")
* [Configure fields](https://servicenow-prod.fluidtopics.net/oOs55ePFJIhxoE4qG9076g "Learn about how fields in CPQ help structure data collection efficiently and about the various types of field. Associate fields with blueprints for consistent use across configurations, layouts, and rules.")