--- 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 --- # Blueprints # Blueprints {#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 Blueprints in ServiceNow CPQ Blueprints in ServiceNow CPQ are the core structures that define configuration experiences for products. They act as containers that integrate essential elements---Fields, Rules, Layouts, and Configurable Products---into a unified, manageable framework. This modular and version-controlled approach allows administrators to design, deploy, and manage product configurations efficiently and consistently across environments without duplicating logic or content. Show full answer Show less ## Key Features * **Fields:** Capture relevant data and user inputs, associating only those fields pertinent to a specific configuration experience. * **Rules:** Business logic that controls visibility, validation, dynamic behaviors, and product inclusion, automatically linked based on referenced fields. * **Layouts:** Define the user interface presentation of fields and pickers, with multiple layouts possible per blueprint but each layout unique to one blueprint. * **Configurable Products:** Serve as entry points to launch configurations defined by a blueprint; multiple products can reference a single blueprint, but each product is tied to only one blueprint. * **Enrichments:** Extend functionality beyond rules through advanced scripting, external integrations, or pricing enhancements. ## Blueprint Life Cycle and Management Blueprints follow a clear life cycle: creation, association of components, deployment for end-user access, and migration between environments (development, test, production). They are version-controlled, enabling safe refinement and reuse. The administration interface provides comprehensive visibility and control through tabs for associated fields, rules, layouts, configurable products, deployments, enrichments, and field mappings. ## Deployment and Environment Behavior * **Production:** Blueprints remain active indefinitely after deployment. * **Test:** Blueprints undeploy automatically after 30 days of inactivity, with redeployment resetting the timer. * **Demo:** Blueprints undeploy weekly for maintenance. Deployment notifications keep administrators informed of progress and status. ## Migration and Version Control Blueprints can be exported and imported with all related components to facilitate environment migrations and version control. During import, administrators can adjust product IDs, rule mappings, and environment-specific references to ensure compatibility. Unique IDs for configurable products are maintained to preserve data integrity. ## Best Practices for ServiceNow Customers * Create modular blueprints aligned with each major product or configuration flow for clarity and maintainability. * Use descriptive names for blueprints and variables to simplify management and review. * Regularly audit inactive rules to avoid reintroducing outdated logic. * Deploy changes first in controlled environments before promoting to production. * Document enrichment scripts and external integrations to maintain transparency and support. Learn how blueprints define the structure of configuration experiences in ServiceNow CPQ and act as containers for fields, rules, layouts, and configurable products. Blueprints are the foundation of every configuration experience in ServiceNow CPQ. They define the structure, behavior, and visual layout of configurations by linking together all key elements---Fields, Rules, Layouts, and Configurable Products---into a single, manageable container. A blueprint represents the complete configuration logic for one product or experience and ensures consistent behavior across environments. By using blueprints, administrators can design, deploy, and manage configuration workflows without duplicating content or logic. Each blueprint provides a modular, versioned space to build and refine configuration experiences safely before deploying them to production. ## Blueprint components {#blueprints__section_d1b_cpb_fhc} A blueprint brings together several key elements that define how a configuration behaves and appears to end users. * Fields: Capture data and user input. Blueprints associate only the subset of global fields relevant to that configuration experience. * Rules: Define the business logic that governs visibility, validation, product inclusion, and dynamic behaviors. Rules automatically connect to blueprints when their referenced fields are associated. * Layouts: Determine how fields and pickers appear in the UI. Each Layout is unique to a single blueprint, though a blueprint can contain multiple Layouts. * Configurable Products: Act as the entry point that launches the configuration defined by a blueprint. Multiple products can reference a single blueprint, but each product can only belong to one blueprint. * Enrichments: Extend logic beyond the rules engine to handle advanced scripting, external connections, or pricing enrichments. {#blueprints__ul_yfq_cpb_fhc} ## Blueprint life cycle {#blueprints__section_uqq_dpb_fhc} Blueprints are version-controlled entities that progress through a simple life cycle: creation, association, deployment, and migration. * Create: Define a new blueprint record and assign a name. * Associate: Link fields, rules, layouts, and configurable products to the blueprint. * Deploy: Make the blueprint available for end-user configurations in your environment. * Export/Import: Move blueprints between development, test, and production environments for versioning and reuse. {#blueprints__ol_zy1_2pb_fhc} ## Blueprint administration interface {#blueprints__section_a1q_2pb_fhc} Each blueprint record includes multiple tabs that provide visibility into its structure and related components: * Associated Fields: View all fields and subfields linked to the blueprint, organized by type (Standard, Sets, product pickers, System). * Related Rules: Review active and inactive rules automatically linked through field references. * Layouts: View or modify layouts associated with the blueprint. The most recently saved layout is used by default during runtime. * Configurable Products: View all products that launch the configuration experience defined by the blueprint. * Deployments: Track the most recent deployments, including date, user, and status. * Enrichments: Manage enrichment scripts that run outside the rules engine (for example, initialization or pricing scripts). * Field Mapping: View and manage field mapping for context variables. {#blueprints__ul_q2d_fpb_fhc} ## Deployment and environments {#blueprints__section_hv1_3pb_fhc} Deployments make a blueprint visible to end users. All associated changes---fields, rules, layouts, and configurable products---become active upon deployment. Deployment notifications appear in the lower-left corner of the Admin interface, showing status updates such as "In Progress" or "Completed". Deployment behavior varies by environment type: * Production: Deployed blueprints remain active indefinitely. * Test: Automatically undeployed after 30 days of inactivity (reset upon redeployment). * Demo: Automatically undeployed every weekend for maintenance. {#blueprints__ul_ylt_3pb_fhc} ## Migration and version control {#blueprints__section_y3b_kpb_fhc} Blueprints can be exported and imported across environments to support development life cycles and version control. The exported package includes all related elements such as fields, rules, and layouts, allowing you to migrate configurations without manually recreating components. When importing, administrators can update Product IDs, rule mappings, and environment-specific references to ensure compatibility in the target org. ServiceNow CPQ maintains unique IDs for each Configurable Product to preserve data integrity across environments. ## General guidelines {#blueprints__section_vrz_kpb_fhc} * Create modular blueprints for each major product or configuration flow. * Use descriptive names and variable names for clarity and maintainability. * Review inactive rules regularly to prevent outdated logic from re-entering deployments. * Deploy changes in a controlled environment before promoting to production. * Document the enrichment scripts and custom external connections that are used by each blueprint. {#blueprints__ul_yhm_lpb_fhc} **Related concepts** * [Set up blueprints](https://www.servicenow.com/docs/r7NEHhteovBWoG_gPDksaQ "Blueprints define the structure of a configuration experience in ServiceNow CPQ. They act as containers that bring together fields, rules, layouts, and configurable products, enabling administrators to design, deploy, and manage complete configuration workflows across environments.")