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


---

# Fields

# Fields {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 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 Fields

Fields are the fundamental data elements in ServiceNow CPQ configurations, representing individual pieces of data such as quantities, choices, or notes.
They underpin the user interface, logical rules, and downstream outputs like the bill of materials (BOM) or external integrations.
Fields are global within an environment, allowing reuse across multiple blueprints, rules, and layouts to maintain consistency and reduce duplication.
A field becomes part of a specific configuration only when associated with a blueprint, which automatically links related rules without extra steps.
Show full answer Show less  

## How Fields Integrate in CPQ Configuration

* **Blueprints:** Define which global fields are included in configurations, enabling reuse without cloning.
* **Rules:** Use field values as inputs to perform actions such as validation, visibility control, and product additions.
* **Layouts:** Arrange fields visually and select display components to control user interaction.
* **BOM/Product List:** Map field values to product attributes or extended properties for downstream processing.

## Field Lifecycle and Scope

Fields are created once with a unique identifier and are globally accessible. Their lifecycle includes:

* **Create:** Define field type, name, and variable name.
* **Associate:** Link fields to one or more blueprints for configuration inclusion.
* **Display:** Choose appropriate component types (e.g., grid, slider, read-only) in layouts.
* **Orchestrate:** Use rules to manipulate field values, visibility, and product actions.

## Choosing the Right Field Type

Selecting the correct field type ensures data validity and simplifies rule logic. Common types include:

* **Text:** Free-form strings with optional constraints.
* **Number:** Numeric input with min/max and formatting options.
* **Boolean:** True/False with customizable labels.
* **Picklist:** Single or multi-select with defined options and extensions for richer data.
* **Product Picker:** Specialized for selecting products, adding to BOM, and mapping product data.
* **Sets:** Tabular collections for scenarios like calendar entries or line items.

Using constrained types like picklists and product pickers is recommended to reduce validation complexity and guide users effectively.

## Data Model vs. Display Model

The field type governs the data model and valid values, while the Component display type controls the user interface presentation. A single field can have multiple display types across different layouts, maintaining consistent data while adapting user experience. For example, a number field may appear as a slider, read-only text, or formatted currency depending on the layout.

## Association and Reuse

Because fields are global, reuse is straightforward: associate a field with any blueprint needing it, making it available to related layouts and rules. This approach prevents cloning, reduces configuration drift, and simplifies maintenance across multiple products and experiences.

## Governance and Naming Best Practices

* Use clear, stable variable names with underscores to enhance script readability and durability.
* Document field intent and valid ranges in descriptions to support future reuse.
* Set default values only when a starting state is essential; otherwise, allow rules to determine values contextually.

## Accessibility and Internationalization

Choose display types that clearly present options (e.g., radio buttons or tiles) for smaller option sets. Provide human-readable labels, helpful text, and use Markdown for structured guidance. Apply locale-aware formatting for numbers and currency at the layout level to accommodate international users.

## Performance and Reliability Tips

* Use the simplest field types that meet requirements to minimize rules and validations, improving performance.
* Leverage picklist extensions and product pickers to encapsulate complex option data and reduce rule complexity.
* Reserve always-on determination rules for true system defaults and prefer contextual conditions for other logic.

## Bulk Operations

For large-scale changes or environment migrations, use Matrix Loader to bulk-create and edit fields and options. This spreadsheet-based tool also serves as documentation and accelerates progression from development through testing to production.  
Learn how fields provide the foundational data model for ServiceNow CPQ configurations---what they are, how they relate to blueprints, rules, and layouts, and how to choose the right type and display for reliable, reusable experiences.
Fields are the smallest unit of the ServiceNow CPQ configuration model and represent a single piece of data (for example, a quantity, a choice, or a note). They power the user experience (what the user sees and edits), the logical model (what rules read and act
on), and downstream outputs (what is written to the bill of materials or passed to external systems). Because fields are global in an environment, the same field can be reused across blueprints, rules, and layouts to ensure consistency
and reduce duplication.

Fields become part of a specific configuration only when they are associated with a blueprint. When all fields referenced by a rule are associated to a blueprint, the rule is intrinsically related to the blueprint---no extra linking
step is required.

## How fields fit into the configuration model {#fields__section_otq_hsc_fhc}

* Blueprints: Declare which global fields participate in a configuration. Association enables reuse without cloning.
* Rules: Read field values as inputs and perform actions on fields (determine values, show/hide, validate, filter options, add products).
* Layouts: Place fields visually and select a Component display type to control how the user interacts with each field.
* BOM/product list: field values can be mapped to product attribution or extended properties for downstream processing.
{#fields__ul_tqd_3sc_fhc}

## Field scope and life cycle {#fields__section_trd_jsc_fhc}

Fields are created once and available globally. Their life cycle is lightweight and designed for reuse:

1. Create: Define the field type, name, and unique variable name (global identifier).
2. Associate: Add the field to one or more blueprints to make it available in those configurations.
3. Place Display: Choose the appropriate Component display type in a layout (for example, grid, visual picker, slider, read-only).
4. Orchestrate: Apply rules to read or set field values, control visibility, present messages, and drive product actions.
{#fields__ol_lrq_jsc_fhc}

## Choosing the right field type {#fields__section_y1m_ksc_fhc}

Selecting the correct type ensures valid data and simpler rules:

* Text: Free-form string input (up to 2000 characters), with optional length constraints and default.
* Number: Numeric input with optional min/max; layout-level options can enforce step or precision and formatting (currency/percent/read-only currency).
* Boolean: True/False with customizable labels and default state.
* Picklist (single or multi-select): Constrained choices with definable options, defaults, and picklist extensions for rich, columnar option data and implicit filtering.
* Product Picker: A picker specialized for products that can add items to the BOM and map additional data to Product List fields---often removing the need for separate rules.
* Sets: Tabular collections where each row's subfields interact row-locally (ideal for calendar-like or line-item scenarios).

{#fields__ul_dkb_lsc_fhc}  
Note:  
Prefer constrained types (number, picklist, product picker) when possible. Clear constraints reduce validation logic and improve end-user guidance.

## Data model vs. display model {#fields__section_evp_nsc_fhc}

The field type defines the data model and specifies what values are valid. The Component display type defines how users interact with the field in a layout (for example, radio, menu, or grid). A single field can be rendered
differently across layouts while preserving a consistent data model.  
Examples:

* Number: shown as number input, number-with-submit, slider, read-only text/currency, or formatted number.
* Picklist: shown as traditional menu, vertical radio buttons or check boxes, visual tiles, or grid (with picklist extension columns).
* Product Picker: shown as a grid or visual tile experience with subfields and aggregates.
{#fields__ul_mvk_xdd_fhc}

## Association and reuse {#fields__section_ybb_ydd_fhc}

Because fields are global, reuse is the default. Associate a field with any blueprint that needs it; the field is then available to the blueprint's layouts and rules. If all referenced fields in a rule are associated with the
blueprint, the rule is automatically considered related to the blueprint.

This model avoids cloning, reduces drift, and simplifies maintenance across products and experiences.

## Governance and naming {#fields__section_ojj_zdd_fhc}

* Variable names: Use clear, stable, names (with words separated by underscores, as in shipping_method) to make rule scripts expressive and durable.
* Descriptions: Document intent and valid ranges (minimum and maximum, semantic meaning) to aid future reuse.
* Defaults: Set only when the business logic expects a starting state; otherwise, let rules determine values contextually.
{#fields__ul_k2z_zdd_fhc}

## Accessibility and internationalization {#fields__section_phx_c2d_fhc}

* Prefer display types that make choices obvious (radios/tiles) when option sets are small.
* Provide human-readable labels and help text; use read-only text with Markdown for structured guidance.
* Use layout-level formatting for numbers and currency to respect locale conventions.
{#fields__ul_npk_d2d_fhc}

## Performance and reliability tips {#fields__section_vd1_22d_fhc}

* Choose the simplest field type that satisfies the requirement. Fewer rules and validations mean faster run times.
* Use picklist extensions or product pickers to encapsulate rich option data and reduce rule count.
* Reserve "always-on" determination rules for true system defaults; prefer contextual conditions elsewhere.
{#fields__ul_rql_22d_fhc}

## When to use bulk operations {#fields__section_iyw_22d_fhc}

For larger changes or environment migrations, use Matrix Loader to bulk-create and edit fields and field options. The spreadsheet artifact doubles as documentation and accelerates flow from dev to test to production.
**Related concepts**   

* [Configure fields](https://www.servicenow.com/docs/qJ6oxfWVfSmKTZLa_Ly08g "Learn about how fields in ServiceNow 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.")