Fields
Summarize
Summary of Fields
Fields are the fundamental data elements within ServiceNow CPQ configurations, representing individual pieces of data such as quantities, choices, or notes. They serve as the basis for user interaction, logical rule processing, and downstream outputs like bills of materials or external system integrations. Fields are global within an environment and can be reused across multiple blueprints, rules, and layouts to maintain consistency and reduce duplication.
Show less
Fields become part of a specific configuration when associated with a blueprint, and rules that reference these fields are automatically linked to the blueprint without additional steps.
How Fields Integrate in the Configuration Model
- Blueprints: Declare which global fields participate in a configuration, enabling reuse without cloning.
- Rules: Use field values as inputs to perform actions such as validation, visibility control, and product additions.
- Layouts: Visually place fields and select display components to define user interaction.
- BOM/Product List: Map field values to product attributes or extended properties for downstream processing.
Field Scope and Lifecycle
Fields are created once and available globally, designed for reuse through a lightweight lifecycle:
- Create: Define field type, name, and unique global identifier.
- Associate: Link fields to one or more blueprints for availability.
- Place Display: Choose appropriate component display types in layouts (e.g., slider, grid, read-only).
- Orchestrate: Apply rules to manipulate field values, control visibility, and drive product actions.
Choosing the Right Field Type
Selecting the appropriate field type ensures data validity and simplifies rule logic. Types include:
- Text: Free-form strings up to 2000 characters.
- Number: Numeric inputs with optional range and formatting controls.
- Boolean: True/False with customizable labels and defaults.
- Picklist (single/multi-select): Constrained choice sets with options and filtering.
- Product Picker: Specialized picker for adding products to BOM and mapping product data.
- Sets: Tabular collections for row-local data interactions, ideal for line-item or calendar scenarios.
It is recommended to prefer constrained types like picklists and product pickers to reduce validation logic and enhance user guidance.
Data Model vs. Display Model
The field type defines valid data and the data model, whereas the Component display type controls how users interact with the field in layouts. A single field can be displayed differently across layouts (e.g., number as slider or read-only text; picklist as radio buttons or grids) while maintaining a consistent underlying data model.
Association and Reuse
Fields are globally reusable and can be associated with multiple blueprints. This avoids cloning, reduces configuration drift, and simplifies maintenance. When all fields referenced by a rule are associated with a blueprint, the rule is intrinsically linked to that blueprint.
Governance and Naming Best Practices
- Variable Names: Use clear, stable names with underscores for expressiveness and durability (e.g., shippingmethod).
- Descriptions: Document intent, valid ranges, and semantic meaning to support future reuse.
- Defaults: Set only when a business logic starting state is required; otherwise, allow rules to determine values contextually.
Accessibility and Internationalization
- Use display types that clearly present choices (e.g., radios, tiles) especially for small option sets.
- Provide human-readable labels and help text, using Markdown in read-only text for structured guidance.
- Apply layout-level formatting for numbers and currency to respect local conventions.
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 data and reduce rule counts.
- Reserve always-on determination rules for true system defaults; use contextual conditions for other scenarios.
Bulk Operations
For large-scale changes or environment migrations, use Matrix Loader to bulk-create and edit fields and options. This approach doubles as documentation and accelerates transitions from development to test and production 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
- Create: Define the field type, name, and unique variable name (global identifier).
- Associate: Add the field to one or more blueprints to make it available in those configurations.
- Place Display: Choose the appropriate Component display type in a layout (for example, grid, visual picker, slider, read-only).
- Orchestrate: Apply rules to read or set field values, control visibility, present messages, and drive product actions.
Choosing the right field type
- 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).
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.
- 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.