CPQ Guide

Tag: PDM integration

  • Common CPQ Integration Patterns

    CPQ integration connects Configure, Price, Quote software with the systems that hold customer, product, engineering, commercial and manufacturing data. In manufacturing, CPQ may exchange configuration rules, product options, dimensions, prices, costs, bills of material, drawings, customer records, inventory data and sales orders with other enterprise applications.

    The most common pattern is a CPQ application positioned between customer-facing sales channels and operational systems. A CRM system may initiate an opportunity, CPQ validates the configurable product and calculates the quote, PLM or PDM supplies released engineering data, CAD automation creates product-specific outputs, and ERP receives the approved order, pricing and manufacturing data. The exact design depends on which capabilities the CPQ platform provides and which system owns each data domain.

    CPQ should not be treated as a replacement for enterprise resource planning (ERP), product lifecycle management (PLM), customer relationship management (CRM), computer-aided design (CAD) or manufacturing execution systems (MES). It is an orchestration and decision point in the manufacturing technology stack, but it should not automatically become the master for every type of data.

    What is a CPQ integration pattern?

    A CPQ integration pattern is a repeatable architectural approach for exchanging data and coordinating actions between CPQ and another system. The pattern describes the direction of data flow, the trigger, the interface technology, the system responsible for each record and the response when an integration fails.

    For example, a CRM-to-CPQ pattern may create a quote from an opportunity. A PLM-to-CPQ pattern may publish released product options and engineering rules. A CPQ-to-ERP pattern may send an approved configuration, price, customer information and order lines for order entry. These are different integrations even when they use the same API platform.

    Manufacturing CPQ integrations commonly support four related activities:

    • Configuration: validating options, dimensions, materials, capacities, motors, accessories and dependencies.
    • Engineering: performing calculations, selecting components, generating a configurable bill of material (BOM), or requesting CAD outputs.
    • Commercial processing: calculating cost, price, discounts, margins, currencies, taxes and approvals.
    • Order and production handoff: transferring an approved configuration and its identifiers to ERP, MES, PLM, PDM or production systems.

    The main systems connected to manufacturing CPQ

    System Typical responsibility Typical CPQ integration
    CRM Accounts, contacts, opportunities and sales activities Creates configuration sessions, quotes and commercial status updates
    ERP Items, customers, inventory, orders, purchasing, finance and fulfillment Provides item and commercial data; receives approved quotes or sales orders
    PLM Product lifecycle, revisions, releases and engineering change processes Publishes approved product structures, options and revisions
    PDM Engineering files, CAD documents, metadata and design relationships Provides or receives CAD documents and product-specific files
    CAD Geometry, assemblies, models and drawings Receives parameters and returns models, drawings or calculated properties
    MES Shop-floor execution, work instructions and production tracking Receives production-relevant configuration or routing information where supported
    PIM Product information and channel content Provides descriptions, images and publishable option information
    API and integration platform Transport, transformation, orchestration, monitoring and security Connects CPQ to multiple systems through APIs, events or files

    These responsibilities often overlap in practice. For example, an ERP may contain sellable item masters while PLM owns engineering revisions, and a CPQ product model may contain the commercial rules needed to present those items to a user. The integration must define how these records relate rather than assuming that one system contains the complete product definition.

    Common CPQ integration patterns

    1. CRM-embedded CPQ

    In a CRM-embedded pattern, users open CPQ from an opportunity, account or quote record in the CRM. The CPQ session receives customer, currency, territory, sales channel and opportunity information. The resulting quote, status, value and approval state are written back to the CRM.

    This pattern is useful when sales teams manage the commercial process in CRM but need a more capable manufacturing configuration model. A sales engineer might select a pump package, enter flow and pressure requirements, choose motor voltage and materials, and return a validated quote to the opportunity.

    The main design question is whether the CRM quote is the commercial system of record or whether CPQ owns the detailed quote and CRM stores only a reference and summary. Duplicating every configuration line in both systems increases synchronization risk.

    2. ERP-centered CPQ integration

    In an ERP-centered pattern, CPQ exchanges item, customer, pricing, availability and order data with the enterprise resource planning system. CPQ may use ERP item numbers and price lists while adding configuration logic that ERP does not support.

    After approval, CPQ can send an order-ready payload containing the configured item, component lines, quantities, selected options, prices, delivery details and references to documents. ERP then handles order management, purchasing, inventory, financial processing and fulfillment.

    This pattern works well for configure-to-order (CTO) products with stable item masters and repeatable manufacturing structures. It becomes more complex when the configuration creates new engineered items, requires a nonstandard BOM, or needs a CAD-derived drawing before the order can be accepted.

    3. PLM or PDM product-data synchronization

    In a PLM-to-CPQ pattern, product lifecycle management supplies released product definitions, revisions, options, attributes and engineering relationships. Product data management (PDM) may provide CAD files and document metadata.

    CPQ normally should not expose unreleased engineering alternatives or obsolete revisions. A controlled publication process can extract only approved options, valid dates, compatible components and customer-facing descriptions. CPQ then adds the rules needed for selling and configuring those choices.

    For example, PLM may define that a particular impeller revision is released for a pump family. CPQ may apply the commercial and application rule that the impeller is available only for certain flow ranges, materials and shaft arrangements.

    4. CAD automation and engineering-service integration

    Some manufacturing CPQ environments connect to CAD or an engineering calculation service. CPQ sends parameters such as length, width, capacity, nozzle location, motor size or mounting arrangement. The CAD service may return a 3D model, 2D drawing, mass properties, calculated dimensions or a document identifier.

    This is particularly relevant to engineer-to-order (ETO) and complex configure-to-order products. It is not a standard capability of every CPQ system. Where CAD automation is available, the integration must define parameter mapping, units, tolerances, file formats, revision control, processing time and failure handling.

    A useful implementation separates the commercial configuration from the CAD generation job. The user can receive an immediate configuration result while a background engineering service generates documents. The quote should clearly indicate whether a drawing is preliminary, automatically generated, or subject to engineering approval.

    See the CAD and engineering automation guide for related design automation patterns.

    5. Configurable BOM and manufacturing handoff

    CPQ may generate a configurable BOM from the selected options. A BOM is a bill of material: the components, subassemblies and quantities required for a product. The output may be a sales BOM, an engineering BOM (EBOM), a manufacturing BOM (MBOM), or a reference used to create one of these structures elsewhere.

    An EBOM represents an engineering view of the product. An MBOM represents how the product is assembled or manufactured. They are related but not interchangeable. CPQ may generate neither directly, may generate a sales or configurable BOM, or may trigger ERP or PLM to create a controlled downstream structure.

    For example, selecting a stainless-steel pump, a 15 kW motor and a particular seal arrangement could generate component requirements and an engineering reference. ERP or PLM may then apply manufacturing-specific operations, phantom assemblies, packaging items and plant-specific substitutions.

    The integration should identify whether CPQ sends component item numbers, quantities, effectivity dates, option codes, configuration identifiers or a complete structure. It should also define how revisions and substitutions are handled.

    6. Event-driven integration

    In an event-driven pattern, systems publish events such as ConfigurationCompleted, QuoteApproved, ProductRevisionReleased or OrderCreated. Other systems subscribe and perform related actions.

    For example, approval of a quote could publish an event that triggers document generation, updates the CRM opportunity, reserves a configuration identifier and starts an ERP order process. Event-driven integration reduces direct dependencies between applications, but it requires reliable event delivery, idempotency, monitoring and a way to reconcile missed or duplicated events.

    Events are usually best for business state changes rather than large product-data transfers. A QuoteApproved event may contain an identifier and status, while the receiving system retrieves the detailed quote through an API.

    7. API-led and integration-platform patterns

    API-led integration exposes reusable interfaces for customers, products, configuration sessions, prices, quotes, documents and orders. An integration platform may transform data, route messages, manage authentication, retry failed calls and record audit information.

    A common architecture uses separate APIs for system access, business capabilities and user channels. For instance, a dealer portal, an ecommerce configurator and an internal sales application may all call the same CPQ configuration service while using different interfaces.

    This approach supports headless CPQ, where the configuration and pricing services are separated from the presentation layer. It can also reduce point-to-point connections, although it introduces governance requirements for API versions, schemas, access rights and service ownership.

    8. Batch and file-based integration

    Not every integration needs real-time APIs. Scheduled files may be appropriate for price lists, item catalogs, product attributes, inventory snapshots, dealer updates or legacy ERP interfaces.

    Batch integration is easier to introduce in some environments, but it creates latency. A price change may not reach CPQ until the next scheduled load. A product revision may remain available after it has been withdrawn from engineering. File-based processes therefore need effective dates, validation reports, rejected-record handling and reconciliation.

    9. Dealer, distributor and ecommerce integration

    Manufacturers often expose CPQ to dealers, distributors or self-service customers. A dealer portal may authenticate users, apply channel pricing, limit visible options and submit configurations for internal review. Ecommerce may use CPQ services to configure a product before creating a cart or order.

    These channels require more than a product catalog. They may need customer-specific price lists, regional availability, channel permissions, lead-time logic, document generation and a controlled handoff to internal sales or engineering teams.

    Data ownership is the central integration decision

    Many CPQ integration failures result from unclear ownership rather than unsuitable technology. Before building interfaces, assign a system of record for each data domain.

    Data domain Possible system of record Questions to resolve
    Customer and account CRM or ERP Which system owns identity, credit status and account hierarchy?
    Released engineering product PLM or PDM Which revisions and effectivity dates may CPQ publish?
    Configuration rules CPQ, PLM or a governed rules repository Who owns compatibility, dependency and validation logic?
    Sellable item and inventory ERP How are item numbers, availability and substitutions exposed?
    Cost ERP, costing system or CPQ Which costs are estimated, standard, plant-specific or contractual?
    Customer price ERP, CPQ or commercial pricing system How are discounts, currencies, approvals and validity dates controlled?
    CAD files and drawings PDM, PLM or CAD system How are generated documents versioned and approved?
    Manufacturing structure ERP, PLM or MES Does CPQ create an MBOM or only provide configuration inputs?

    CPQ may calculate a result without owning the underlying master data. For example, it can use an ERP price list to calculate a quote while retaining a snapshot of the price used at the time of quoting. That snapshot is important for auditability when the ERP price changes later.

    Choosing synchronous, asynchronous or batch communication

    Synchronous integration waits for an immediate response. It is suitable for checking customer status, validating an option, retrieving a current price or confirming whether an item exists. The user experience depends on the response time and availability of the connected system.

    Asynchronous integration submits a request and processes the result later. It is better for CAD generation, complex engineering calculations, large BOM creation or document rendering. The interface should show job status and provide a clear error or retry path.

    Batch integration processes records on a schedule. It is often suitable for large catalogs and legacy systems, but not for decisions that require current availability or real-time approval.

    Requirement Often suitable pattern Primary risk
    Validate a motor and voltage combination Synchronous API Slow or unavailable dependency blocks configuration
    Generate a product-specific drawing Asynchronous job Unclear status or failed document generation
    Load thousands of item descriptions Batch file or bulk API Stale or partially rejected data
    Notify systems that a quote was approved Business event Duplicate or missed event processing

    Integration design considerations for manufacturing

    Product model and rule synchronization

    Configuration rules include required options, exclusions, dependencies, ranges and calculations. A rule such as a pump motor needing to meet a calculated power requirement may not be represented by a simple item catalog. Decide whether the rule is maintained in CPQ, derived from engineering data, or shared through a governed rule service.

    Rules should be versioned with the product model. Testing must cover valid combinations, invalid combinations, boundary values, units and product revisions.

    Identifiers, revisions and effectivity

    Use stable identifiers for products, options, components, configurations and documents. Separate internal identifiers from display names. Every integration should define revision behavior and effective dates. A quote created under revision A should not silently become revision B because a later synchronization replaced the product model.

    Units, currencies and precision

    Industrial products use dimensions, flow rates, pressures, temperatures, loads and electrical ratings. Interfaces must define units and conversion rules. The same discipline applies to currencies, tax treatment, rounding, decimal precision and currency conversion dates.

    Errors, retries and reconciliation

    Integration errors should be visible to the responsible team. A failed ERP order, unavailable CAD service or rejected item should not leave CPQ showing a completed handoff. Use correlation IDs, structured error messages, retry rules and reconciliation reports. Idempotency is important: retrying the same approved quote should not create duplicate orders.

    Security and auditability

    Restrict access by user, channel, plant, product family and action where necessary. Record who changed a configuration, which product revision was used, which price was applied and when the quote was approved. Dealer and customer-facing interfaces require especially careful protection of cost, margin, engineering documents and internal options.

    Benefits and limitations of CPQ integration

    Well-designed integration can reduce rekeying, preserve configuration context, shorten sales-to-engineering handoff, improve price consistency and provide production teams with more reliable order information. It can also make product changes easier to govern because released data and selling rules move through defined publication processes.

    Integration does not automatically fix poor product data or inconsistent processes. Common limitations include duplicate product models, unclear ownership, legacy systems without suitable interfaces, slow engineering services, incomplete BOM mappings and conflicting revision schemes. A highly connected architecture can also become difficult to test if every change requires coordinated releases across several applications.

    A practical implementation sequence

    1. Map the workflow: document how a product moves from lead or opportunity through configuration, quote, approval, order and production.
    2. Inventory data: identify product options, rules, item numbers, prices, costs, BOMs, drawings, customers and revisions.
    3. Assign ownership: decide which system creates, approves, changes and publishes each data domain.
    4. Define the minimum payload: include only the identifiers and values required by the receiving system, plus configuration and revision references.
    5. Select the interaction style: choose synchronous APIs, asynchronous jobs, events or batch transfers based on timing and volume.
    6. Build a vertical slice: test one representative product family from configuration through an approved order or engineering handoff.
    7. Test exceptions: include invalid combinations, unavailable items, price changes, revision changes, duplicate messages, timeouts and partial failures.
    8. Establish governance: manage API versions, product releases, rule ownership, monitoring, support procedures and regression testing.

    The manufacturing CPQ integrations guide provides broader coverage of ERP, CRM, PLM, PDM, CAD, MES, PIM and API connectivity. Product model and rule design are covered in the product configuration guide, while BOM, costing and quote data are discussed in the BOM, pricing and quoting guide.

    Semantic map

    The following relationships summarize the main entities and flows discussed in this article:

    • CPQ connects customer-facing channels with manufacturing systems.
    • CRM provides opportunities and customer context to CPQ.
    • PLM publishes released product definitions to CPQ.
    • PDM manages engineering documents and CAD metadata.
    • Configuration rules prevent invalid product combinations.
    • CPQ calculates prices from products, costs, rules and commercial policies.
    • Configured products can generate configurable BOM data.
    • CAD automation generates product-specific drawings and models.
    • ERP receives approved order and commercial information.
    • MES may receive production-relevant configuration data.
    • Events communicate business state changes between systems.
    • Data ownership governs which system creates and changes each record.

    Frequently asked questions

    1. What is CPQ integration in manufacturing?

    It is the exchange of product, configuration, engineering, pricing, customer, quote and order data between CPQ and systems such as ERP, CRM, PLM, PDM, CAD and MES.

    2. Does CPQ replace ERP?

    No. CPQ may calculate a configuration and quote, while ERP usually manages items, inventory, orders, purchasing, finance and fulfillment. Some CPQ platforms can perform functions that overlap with ERP, but the systems have different primary responsibilities.

    3. How does CPQ integrate with CRM?

    CRM typically provides the opportunity, customer, territory and sales context. CPQ creates or manages the detailed configuration and quote, then returns status, value, documents and references to CRM.

    4. How does CPQ integrate with ERP?

    CPQ may retrieve items, prices, availability and customer data from ERP and send an approved configuration, quote or sales order back to ERP.

    5. Should ERP or CPQ own pricing?

    There is no universal answer. ERP may own standard prices and financial data, while CPQ may apply configuration-dependent pricing, discounts and approvals. The ownership, validity dates and price snapshot must be explicit.

    6. Can CPQ integrate with PLM?

    Yes, where both systems provide suitable interfaces. PLM can publish released products, revisions and engineering relationships, while CPQ applies selling and configuration logic to those products.

    7. Is PDM the same as PLM?

    No. PDM primarily manages engineering files, CAD documents and related metadata. PLM generally covers a broader product lifecycle, including revisions, releases, changes and product structures.

    8. Can CPQ generate a BOM?

    Some manufacturing CPQ platforms can generate a configurable or sales BOM, but this is not universal. Buyers should verify whether the output is an EBOM, MBOM, sales BOM or input for another system.

    9. What is the difference between an EBOM and an MBOM?

    An EBOM is an engineering view of product components. An MBOM is a manufacturing view organized for assembly or production. CPQ output may need transformation before it becomes an MBOM.

    10. When should CAD integration be asynchronous?

    Use asynchronous processing when CAD generation, engineering calculations or document creation may take significant time or depend on an external service.

    11. What is an event-driven CPQ integration?

    It uses business events such as QuoteApproved or ProductRevisionReleased to notify other systems that a state change has occurred. Subscribers then retrieve data or perform related actions.

    12. Are batch files suitable for CPQ integration?

    They can be suitable for large catalog, price or item updates and for legacy systems. They are less suitable when CPQ requires real-time availability, current pricing or immediate validation.

    13. What should a CPQ order payload contain?

    It may contain customer and delivery references, configuration ID, product and revision IDs, option values, quantities, prices, discounts, BOM references, documents and approval status.

    14. How should product revisions be handled?

    Store the revision used by each configuration and quote. Do not silently replace it with a newer revision. Define effectivity dates and rules for reconfiguration or engineering review.

    15. What causes CPQ integration failures?

    Common causes include unclear data ownership, inconsistent identifiers, duplicate product models, missing units, unsupported legacy interfaces, incomplete BOM mappings, unhandled timeouts and poor revision control.

    16. Is an integration platform required?

    No. Direct APIs may be sufficient for a small number of stable connections. An integration platform becomes more useful when transformation, routing, monitoring, retries and many connected systems are required.

    17. How does CPQ support engineer-to-order products?

    CPQ can capture requirements, apply known rules, estimate price and trigger engineering calculations or CAD generation. It should not be assumed to replace engineering approval for genuinely new designs.

    18. What should manufacturers test before go-live?

    Test valid and invalid configurations, boundary values, prices, revisions, BOMs, CAD jobs, order creation, duplicate messages, system outages, security permissions and rollback or recovery procedures.

  • Augmented Reality in Manufacturing CPQ: Engineering, CAD and Configuration Workflows

    Augmented reality in manufacturing CPQ combines augmented reality (AR) with configure, price, quote (CPQ) processes so users can review a configured product in a real or simulated environment before it is quoted, engineered or manufactured. A CPQ system may use the selected options, dimensions, materials, accessories and engineering outputs to display a product-specific 3D model, identify components, show clearances or guide an assembly review.

    In manufacturing, AR is not simply a visual sales feature. Its value depends on whether the AR experience is connected to a governed product model and reliable engineering data. When connected correctly, a configuration can produce a validated visual representation, a bill of materials (BOM), pricing, drawings and downstream manufacturing information. When it is not connected, AR may show an attractive but generic model that does not represent the product being quoted.

    This guide explains where AR fits in a manufacturing CPQ architecture, how data moves between configuration and engineering systems, which use cases are practical, and what manufacturers should verify before implementation.

    What is augmented reality in manufacturing CPQ?

    Augmented reality in manufacturing CPQ is the use of digital overlays, 3D models and contextual product information to present a configured industrial product in the user’s physical environment or field of view.

    For example, a sales engineer configuring a pump skid could use AR to place the selected skid in a plant area. The visualization might show the chosen pump, motor, frame, pipe connections and control enclosure. It could also display approximate footprint, service access zones and connection locations. The underlying CPQ configuration should determine which model variants and dimensions appear.

    AR is therefore an interaction and visualization layer around CPQ data. It does not replace:

    • Product configuration, which selects valid options and applies dependencies and constraints;
    • Engineering calculation, which determines whether the selected product meets duty, load, capacity or dimensional requirements;
    • CAD, or computer-aided design, which represents product geometry and can produce drawings or design outputs;
    • BOM generation, which identifies components required for a configured product;
    • Pricing and costing, which calculate commercial values; or
    • Enterprise integration, which transfers approved information to systems such as enterprise resource planning (ERP), product lifecycle management (PLM) or customer relationship management (CRM).

    A manufacturing CPQ platform may support some of these functions directly, integrate with specialist systems, or provide only the configuration and quotation layer. Buyers should verify the documented scope of each product rather than assuming that a CPQ system includes native AR, CAD automation or engineering automation.

    How AR fits into a manufacturing CPQ architecture

    A typical architecture contains several connected layers. The product model defines what can be configured. The rules engine validates selections. Engineering services calculate dimensions or performance. CAD and visualization services produce geometry. The AR application displays the resulting model on a device. Commercial and enterprise systems manage pricing, quotes, orders and production data.

    Layer Typical responsibility AR relationship
    Product model Defines options, features, attributes, variants and component relationships. Determines which product components and visual assets may be displayed.
    Rules and constraints Prevents incompatible combinations and validates technical conditions. Prevents the AR view from representing an invalid configuration.
    Engineering logic Calculates capacity, dimensions, performance, loads, clearances or selections. Supplies configuration-specific values and geometry parameters.
    CAD and 3D services Generate or retrieve parametric models, assemblies, drawings and lightweight visualization files. Provide the three-dimensional assets rendered by the AR experience.
    CPQ commercial layer Calculates cost, price, discounts, lead time and quote content. Associates the displayed configuration with a quote or opportunity.
    ERP, PLM, PDM and MES Manage enterprise, lifecycle, design, production and execution data. Supply approved revisions, item identifiers and manufacturing context where required.

    A product data management (PDM) system manages design files and revisions, while PLM manages product lifecycle information, structures, changes and governance. A manufacturing execution system (MES) manages production execution. These systems are related but not interchangeable. An AR application should use approved and traceable data, especially when the visual output is used for engineering review or production support.

    Data flow from configuration to AR

    The exact implementation varies, but a common flow is:

    1. Start with requirements. A user enters application data such as flow rate, pressure, voltage, payload, dimensions, environment or vehicle use case.
    2. Apply configuration rules. The CPQ product model enables valid options and rejects incompatible selections. For example, a motor voltage may be restricted by the selected electrical standard, and a frame size may depend on pump capacity.
    3. Run engineering calculations. A calculation service may determine shaft size, heat exchanger area, structural dimensions, cable length or required safety factors.
    4. Resolve product identity. The system identifies selected components, part numbers, variants and revision-controlled assemblies.
    5. Generate or retrieve 3D data. The solution obtains a lightweight model, a parametric CAD output or a prebuilt 3D asset that matches the configuration.
    6. Apply metadata. Components can be associated with labels, service zones, technical attributes, item numbers, cost information or installation instructions.
    7. Render the AR experience. The user places, rotates, measures or inspects the configured product using a supported device.
    8. Return decisions to CPQ. The user may confirm the configuration, request a change, attach an image to the opportunity or send the result for engineering review.

    The most important control point is the relationship between the product configuration and the 3D output. A model generated from different rules, an old CAD revision or a generic product family may create false confidence. The system should record the configuration version, CAD revision and relevant calculation results where the AR output influences a quote or design decision.

    Manufacturing use cases for AR-enabled CPQ

    Industrial machinery and equipment

    Manufacturers of machinery can use AR to show how a configured machine fits into a customer’s facility. A configured conveyor, packaging machine or material-handling system may include different lengths, guards, drives, access doors and discharge directions. An AR view can help the customer review footprint, operator access and interfaces before quotation approval.

    Pumps, valves and process skids

    For pumps and valves, AR can display selected connection sizes, orientation, actuator position, motor arrangement and service access. In a skid configuration, the visual output can help reveal clashes with adjacent equipment. It should not be treated as a substitute for a certified layout or piping design unless the underlying geometry and engineering process support that use.

    HVAC and electrical equipment

    An HVAC CPQ workflow may use AR to show an air-handling unit, duct connections, service panels and clearance zones in a building area. An electrical equipment configuration may display enclosure dimensions, cable entry locations, busbar sections and selected accessories. Rules still need to validate ratings, environmental requirements and applicable product constraints.

    Specialty vehicles and mobile equipment

    Vehicle and mobile-equipment manufacturers can display a configured body, cab, tank, boom, tool carrier or accessory package. The visualization may support customer review of reach, access and interference. Engineering validation remains necessary for axle loads, structural limits, legal requirements, stability and production feasibility.

    Sales-to-engineering handoff

    AR can make handoff discussions more concrete. A sales engineer can mark a customer concern on the configured model and transfer the same configuration identifier, selected options, dimensions and attachments to engineering. This is more useful than sending an unstructured screenshot, provided the receiving team can trace the visual output back to the controlled product model.

    Installation, service and production support

    After the sale, the same product-specific data may support installation or service guidance. A technician could identify components, access panels or connection points using an approved model. However, this requires revision control and a clear distinction between a sales visualization and an authoritative service or work instruction.

    AR compared with 3D product configuration and CAD automation

    These capabilities overlap but solve different problems.

    Capability Primary purpose Typical output
    3D product configuration Lets users inspect and manipulate a digital representation of a product. Browser-based model, option visualization or interactive assembly.
    CAD automation Creates or modifies engineering geometry from parameters and rules. Parametric CAD file, drawing, assembly or manufacturing geometry.
    Augmented reality Places digital content in a physical context or user field of view. Device-based overlay, spatial review or guided visualization.
    Virtual reality Places the user in a fully digital environment. Immersive simulated facility or product review.

    A CPQ system may offer browser-based 3D without AR, or it may integrate with a separate visualization and AR platform. CAD automation may produce a precise engineering model while AR uses a simplified model for performance. The simplified model must still preserve the dimensions, interfaces and components relevant to the intended decision.

    Benefits for engineering-driven manufacturers

    • Earlier spatial validation: Customers and sales engineers can identify footprint, access and interface problems before order release.
    • Clearer technical communication: A configured assembly can be easier to review than a text description or generic catalogue image.
    • More useful sales-to-engineering handoff: The same configuration identifier and visual context can accompany the request for engineering review.
    • Reduced ambiguity in options: Users can see the practical difference between accessories, orientations, enclosures and connection arrangements.
    • Support for complex products: AR is particularly useful when the product contains many physical options whose effects are difficult to communicate in a quote.
    • Potential reuse of engineering assets: Approved 3D models and metadata may support sales, installation, service and training, subject to governance.

    These benefits depend on data quality. AR cannot correct an incomplete product model, missing constraints, inaccurate CAD geometry or an uncontrolled engineering process.

    Limitations and implementation risks

    Visual accuracy is not engineering validation

    A model can look correct while failing a load, pressure, thermal, electrical or regulatory requirement. CPQ rules and engineering calculations must remain authoritative for those decisions.

    Model preparation can be expensive

    Detailed CAD assemblies may be too large for real-time AR. Manufacturers may need simplified meshes, material definitions, texture optimization, coordinate systems and separate visual variants. This creates another data-maintenance task.

    Configuration and CAD may not align

    A CPQ option may not map cleanly to a CAD feature. Some options change geometry, while others change only metadata, hardware, purchasing items or manufacturing operations. The implementation must define what appears visually and what is represented only in the BOM.

    Revision and lifecycle control are essential

    AR content associated with an obsolete CAD revision can mislead users. The system should define approval states, effective dates, ownership and traceability between product rules, CAD files, visual assets and production structures.

    Devices and operating conditions affect usability

    Lighting, network availability, tracking quality, screen size, protective equipment and factory conditions can affect the experience. A browser or tablet workflow may be more practical than specialized headsets for some sales and engineering teams.

    AR may not be appropriate for every product

    For a small configurable component, a 2D drawing or standard 3D viewer may provide sufficient value. AR is most justified when physical context, spatial relationships or customer understanding materially affect configuration and approval.

    Implementation approach

    1. Select a specific decision to improve. Start with a use case such as equipment footprint review, accessory selection or plant interface validation rather than an open-ended AR project.
    2. Map the authoritative data. Identify which system owns product options, rules, CAD revisions, item numbers, BOM structures, calculations and customer requirements.
    3. Define configuration-to-geometry mappings. Document how each relevant option changes the model, metadata, assembly structure or no visual output at all.
    4. Choose the required fidelity. Decide whether users need a conceptual model, dimensionally reliable layout, engineering CAD output or a service-grade representation.
    5. Design identifiers and traceability. Link the AR session to a configuration ID, quote revision, product revision and, where appropriate, CAD or PLM revision.
    6. Test rule and visual consistency. Test valid and invalid combinations, boundary dimensions, substitutions, obsolete parts and engineering overrides.
    7. Integrate with the sales and engineering workflow. Define how users request review, capture customer approval, transfer comments and update the quote.
    8. Govern changes after launch. Assign ownership for product rules, CAD assets, visual content, device support and release testing.

    Manufacturers should document requirements, integration boundaries and acceptance tests as part of the wider CPQ implementation process. The product model and rule governance should be designed alongside the AR experience, not after it.

    Questions to ask when evaluating AR and CPQ software

    • Does the platform provide native AR, browser-based 3D, or an integration framework?
    • Can the AR model be generated from the exact configured options and dimensions?
    • How are CAD files simplified, versioned and approved?
    • Can visual components be linked to part numbers, BOM items and engineering attributes?
    • Does the solution support parametric geometry, prebuilt variants or both?
    • How are configuration rules shared between CPQ and CAD automation?
    • Can the system distinguish a sales visualization from an engineering-approved model?
    • How are revisions synchronized with PLM or PDM?
    • Can a user return comments, measurements or approval status to the quote?
    • What happens when an option has no visible geometry but changes cost, BOM or manufacturing work?
    • Are offline use, device management and access permissions supported?
    • Can the implementation handle configure-to-order (CTO) and engineer-to-order (ETO) products?

    These questions should be evaluated with representative products, not only a demonstration model. Review a product with dimensional dependencies, optional components, substituted parts and at least one engineering exception.

    Related manufacturing CPQ concepts

    AR is one part of a broader engineering and commercial architecture. Read the guide to CAD and engineering automation for parametric models, drawings and calculations. The guide to product configuration and rules engines explains how options and constraints are modeled. For downstream structures and commercial outputs, see BOM generation, pricing and quoting. The manufacturing workflows guide covers configure-to-order, engineer-to-order and sales-to-engineering handoff. Integration patterns are described in the guide to CPQ integrations.

    Semantic map

    The following relationships summarize how augmented reality connects to manufacturing CPQ and engineering data:

    Entity Relationship Related entity
    CPQ configures configurable industrial products
    Configuration rules prevent invalid option combinations
    Configured product generates configuration-specific BOM
    CPQ exchanges data with ERP
    CAD automation generates product-specific geometry and drawings
    AR application displays configured 3D model
    Engineering calculations determine technical product parameters
    PLM governs product revisions and lifecycle data
    PDM manages CAD files and design revisions
    AR review supports sales-to-engineering handoff
    Configured options control visual components and metadata
    Approved product model supports quote, engineering and production workflows

    Frequently asked questions

    What is augmented reality in manufacturing CPQ?

    It is the use of digital overlays and configured 3D product content to show an industrial product in a physical or spatial context during configuration, quotation, engineering review or service.

    Does every manufacturing CPQ system support augmented reality?

    No. Some systems provide only rules, pricing and quoting. Others include 3D visualization or connect to external CAD, visualization or AR platforms. Native AR capability must be verified with the vendor.

    How is AR different from 3D product configuration?

    3D configuration displays and manipulates a digital product, often in a browser. AR places digital content into the user’s physical environment or field of view. A CPQ solution may provide one without the other.

    Can AR generate a BOM?

    AR normally does not generate the BOM itself. The CPQ or engineering system generates a configurable BOM, while AR displays selected components or metadata associated with that BOM.

    Can AR replace CAD automation?

    No. CAD automation creates or modifies engineering geometry and drawings. AR presents visual content. They can be connected, but they perform different functions.

    What product data does AR-enabled CPQ require?

    It commonly requires product options, configuration rules, dimensions, part identifiers, approved 3D assets, revision information and mappings between configuration selections and visual components.

    Can AR show a completely engineered-to-order machine?

    It can, if the engineering process produces suitable geometry and the AR workflow can consume it. ETO products usually require stronger review, revision and approval controls than standard CTO products.

    How does AR support sales-to-engineering handoff?

    It can provide a shared visual reference and transfer the configuration ID, selected options, dimensions, comments and attachments to engineering. The handoff is reliable only when the visual output remains traceable to controlled data.

    Is an AR model the same as an engineering-approved model?

    Not necessarily. AR often uses a simplified model optimized for performance. It should be labeled according to its purpose and should not be treated as an approved design without the required engineering validation.

    Can AR validate physical clearances?

    It can support an early clearance review when the model, scale, coordinate system and placement method are reliable. Formal layout, safety and compliance decisions may require certified drawings or engineering analysis.

    What is the role of configuration rules in AR?

    Rules ensure that the visualized product reflects valid combinations. For example, they can prevent an AR view from showing an incompatible motor, frame, enclosure or connection arrangement.

    Does AR affect pricing and quoting?

    AR does not inherently calculate price. It can improve option understanding and customer approval, while the CPQ pricing engine calculates cost, price, discounts, lead time and quote values.

    Can AR use data from PLM or PDM?

    Yes, an integration may retrieve approved CAD assets, revisions and metadata from PLM or PDM. The integration must define ownership, release status, access rights and revision synchronization.

    Is AR useful for configure-to-order products?

    Yes. CTO products often have repeatable option structures and reusable visual assets, making them practical candidates for AR-based configuration and customer review.

    Is AR useful for make-to-order and engineer-to-order products?

    It can be useful, but the value depends on how much geometry and engineering data exists before the order. ETO workflows need careful handling of design changes, approvals and model revisions.

    What are the main risks of implementing AR in CPQ?

    Common risks include inaccurate or obsolete models, weak configuration-to-CAD mappings, poor device usability, excessive model detail, unclear data ownership and treating visualization as engineering validation.

    How should a manufacturer start an AR CPQ project?

    Choose one high-value use case, such as reviewing equipment footprint or accessory placement. Map authoritative data, define model fidelity, connect the configuration to visual assets and test the workflow with real product variants.

    What should buyers ask AR and CPQ vendors?

    Ask whether AR is native or integrated, how models are generated and versioned, how options map to geometry, how BOM and CAD data are linked, how revisions are governed and how the result returns to the quote or engineering workflow.