Fields

  • Release version: Zurich
  • Updated October 8, 2025
  • 4 minutes to read
    • Summarize
    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 like quantities, choices, or notes. They underpin the user interface, business logic, and integration outputs, providing a consistent and reusable data model across blueprints, rules, layouts, and downstream processes such as the bill of materials (BOM).

    Show full answer Show less

    Because fields are global within an environment, they can be reused across multiple configurations without duplication. A field becomes part of a configuration when it is associated with a blueprint, which also implicitly links related rules that reference those fields.

    How Fields Integrate with CPQ Configuration

    • Blueprints: Define which global fields are included in a configuration, enabling reuse without cloning.
    • Rules: Use field values as inputs to execute actions such as setting values, controlling visibility, validation, filtering, and adding products.
    • Layouts: Control the visual placement and interaction style of fields by selecting appropriate Component display types.
    • BOM/Product List: Map field values to product attributes or extended properties for downstream workflows.

    Field Lifecycle and Scope

    Fields are created once with a defined type, name, and unique variable name, then associated with one or more blueprints to enable reuse. They are displayed using various Component types to match user interaction needs and are orchestrated through rules to manage behavior and data flow.

    Choosing the Right Field Type

    Selecting the proper field type ensures data validity and simplifies rule creation. Common field types include:

    • Text: Free-form strings with optional length limits.
    • Number: Numeric input supporting min/max, precision, and formatting options.
    • Boolean: True/False with customizable labels.
    • Picklist: Single or multi-select constrained choices with support for rich option data and filtering.
    • Product Picker: Specialized picker for products that integrates with BOM and product lists.
    • Sets: Tabular collections for related subfields, ideal for complex line-item or calendar scenarios.

    Using constrained types where possible improves validation and user guidance.

    Data Model vs Display Model

    The field type defines the underlying data and valid values, while the Component display type controls how users interact with the field in different layouts. This separation allows the same field to be rendered in multiple ways (e.g., sliders, grids, radios) while maintaining data consistency.

    Association and Reuse

    Fields are global and reusable by associating them with any blueprint that requires them. This avoids cloning, reduces configuration drift, and simplifies maintenance. Rules automatically relate to blueprints when all their referenced fields are associated.

    Governance and Best Practices

    • Variable Naming: Use clear, stable names with underscores to enhance script readability and durability.
    • Documentation: Include descriptions of intent and valid ranges to support reuse.
    • Defaults: Set default values only when necessary; rely on rules for contextual logic.
    • Accessibility and Internationalization: Use display types that clarify choices; provide readable labels and help text; respect locale formatting for numbers and currency.

    Performance and Reliability Tips

    • Choose the simplest field type that meets requirements to minimize rules and validations, improving performance.
    • Use picklist extensions and product pickers to encapsulate complex option data and reduce rule complexity.
    • Reserve always-on determination rules for system defaults and prefer contextual conditions for dynamic logic.

    Bulk Operations

    For large-scale changes or migrations, use the Matrix Loader tool to bulk-create and edit fields and options via spreadsheets, which also serve as documentation and facilitate deployments across environments.

    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

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

    Field scope and life cycle

    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.

    Choosing the right field type

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

    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.

    Association and reuse

    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

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

    Accessibility and internationalization

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

    Performance and reliability tips

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

    When to use bulk operations

    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.