CPQ Guide

Tag: rules engines

  • When Excel and Spreadsheets Stop Working for Product Configuration

    Excel and other spreadsheets stop being suitable for product configuration when a manufacturer must coordinate many options, dependencies, engineering calculations, prices, bills of material, drawings and production data across multiple users and systems. A spreadsheet may still calculate a price or help an engineer prototype a product, but it is no longer a reliable configuration system when users can create invalid combinations, overwrite rules, use outdated versions or produce inconsistent manufacturing data.

    For a manufacturer, the question is not whether Excel can represent a product. It often can. The question is whether the spreadsheet can provide controlled, traceable and repeatable configuration decisions from sales through engineering and production. When it cannot, a product configuration system or manufacturing Configure, Price, Quote (CPQ) platform becomes a candidate.

    This does not mean that every company should immediately replace every spreadsheet. Excel remains useful for analysis, temporary calculations, data preparation and controlled engineering work. The issue is whether it is being used as an informal database, rules engine, pricing engine, quoting tool and engineering handoff at the same time.

    This guide explains the practical boundary between a useful spreadsheet and an operational risk, using examples from configurable machinery, pumps, valves, electrical equipment, vehicles and other engineered products.

    What spreadsheets can and cannot do for product configuration

    A spreadsheet can store option lists, calculate dimensions, apply formulas, look up prices and produce a basic quote. With careful design, it can also support a small product family with limited variation. For example, a sales engineer might select a pump model, motor rating, seal material and connection type, then use formulas to calculate a preliminary price.

    The difficulty appears when the spreadsheet must enforce a growing set of relationships. A pump may require a particular impeller when flow and head cross a defined threshold. A hazardous-area motor may require a compatible enclosure and certification. A large valve may require a different actuator, mounting arrangement and material specification. These are product rules, not merely lookup values.

    Spreadsheets typically represent these relationships through nested formulas, hidden worksheets, lookup tables, cell protection, macros and user instructions. The logic may work for its original author but become difficult to understand, test and maintain as the product model evolves.

    Spreadsheet use Where it can work Typical limitation
    Option and price lookup Small product family with stable prices Duplicate or outdated price tables
    Engineering calculation One specialist or a controlled engineering process Unclear version ownership and limited auditability
    Quote preparation Low quote volume and simple products Manual copying and inconsistent revisions
    Configuration rules Few dependencies and well-trained users Rules become hidden in formulas and macros
    BOM preparation Stable assemblies with limited variants Incorrect or incomplete manufacturing structure
    Cross-system data exchange Occasional controlled import or export Manual re-entry and synchronization failures

    The boundary is usually reached when the spreadsheet is no longer a calculation aid and has become the only place where critical product knowledge exists.

    Warning signs that Excel is no longer sufficient

    1. Users need instructions to avoid invalid combinations

    If a workbook contains long notes such as do not select option B with motor type C, the configuration logic is already becoming difficult to control. Human instructions are weaker than a validation rule that prevents the invalid selection or explains why the selection is unavailable.

    For example, a configurable air-handling unit may allow several fan types, coil materials and casing configurations. Some combinations may be technically impossible, while others may fail a customer specification or certification requirement. If users must remember these relationships, the process depends on individual experience rather than a controlled product model.

    2. The workbook contains nested formulas, macros and hidden worksheets

    Complex formulas are not automatically wrong. The problem is that product logic becomes difficult to inspect when it is distributed across hidden columns, named ranges, macros and copied worksheets. A change to one reference can affect price, dimensions, component selection and quote output without an obvious record of what changed.

    This creates a governance problem. A manufacturer may know that the workbook produces an answer but not be able to explain which rule produced it or prove that all relevant scenarios were tested.

    3. Several versions of the same workbook are in circulation

    Version drift is one of the clearest signs that a spreadsheet has become an operational system without system controls. Sales may use one price file, application engineering another, and production a third workbook containing a slightly different component list.

    Even when files have dates in their names, users can save local copies, email attachments or modify formulas. The resulting quote may be based on different product rules from those used to create the order.

    4. The same product data is entered repeatedly

    Repeated entry is common when a salesperson configures a product in Excel, an engineer re-enters the selections into a CAD or engineering tool, and an ERP administrator creates the order manually. Each handoff introduces a chance of changing a dimension, material, quantity, currency or option code.

    Re-entry is particularly risky for products with many repeated components. A configured conveyor, switchboard or mobile work platform may contain hundreds of line items, variants and purchased components. Manual transfer is difficult to verify at that scale.

    5. Engineering reviews most or every quote

    Engineering review is appropriate for genuine Engineer-to-Order (ETO) work, where a product requires new design or significant adaptation. It is a warning sign when engineers spend their time checking routine configurations that should already be governed by standard rules.

    If engineers repeatedly correct sales selections, calculate standard dimensions or rebuild standard bills of material, the company may need a more controlled configuration model rather than additional spreadsheet training.

    6. The workbook cannot generate trustworthy manufacturing data

    A quote is not the same as a manufacturing definition. A customer-facing description may say stainless steel pump package, while production needs exact component numbers, quantities, material grades, machining requirements and assembly relationships.

    When a spreadsheet produces only a text description or an approximate list, an employee must translate it into an engineering bill of material (EBOM), manufacturing bill of material (MBOM), work instructions or an ERP order. That translation is a likely source of errors.

    7. Pricing requires manual exceptions and corrections

    Manufacturing pricing may depend on dimensions, material, purchased components, labor, freight, currency, customer agreements, quantity breaks, surcharge rules and project-specific engineering effort. A spreadsheet can calculate these values, but manual overrides often become invisible or are copied into later versions.

    If users cannot distinguish a calculated price from a manually overridden price, management may lack a reliable audit trail for margin and approval decisions.

    8. A product change requires editing many files

    Suppose a motor supplier changes, a material becomes unavailable or a safety rule changes. If the update requires editing separate workbooks for sales, engineering, purchasing and production, the business has a product-data synchronization problem.

    A controlled product model should identify where the authoritative rule, component, price or document is maintained and how the change reaches dependent processes.

    Why product configuration is harder than a spreadsheet lookup

    Manufacturing product configuration combines several kinds of logic. They should be distinguished because each has different data and maintenance requirements.

    Configuration concept Meaning Manufacturing example
    Option selection Choosing a feature, component or variant Selecting a 15 kW motor
    Rules-based configuration Applying explicit if-then relationships If the enclosure is outdoor-rated, require a weatherproof finish
    Constraint-based configuration Preventing combinations that violate technical or commercial constraints Preventing a valve body and actuator combination outside the available torque range
    Guided selling Asking business-oriented questions that lead to suitable products Asking required flow, pressure and fluid type before recommending a pump family
    Engineering calculation Deriving a value from technical inputs Calculating vessel wall thickness or heat-exchanger area
    Variant generation Creating downstream product data from selections Generating a configured BOM and product-specific drawing

    A spreadsheet may support each of these functions in isolation. The challenge is maintaining them together and ensuring that the same selection drives the quote, engineering output and production data. The product configuration guide explains product models, features, dependencies, constraints and validation in more detail.

    Manufacturing risks of spreadsheet-based configuration

    Configuration errors

    An invalid combination may be accepted because a formula was not copied, a validation list was incomplete or a user bypassed a warning. The error may remain invisible until design review, purchasing or assembly.

    Incorrect bills of material

    A bill of material (BOM) defines the components and quantities required for a product or assembly. A configurable BOM uses rules, selections or variant logic to determine which items belong to a particular configuration. A spreadsheet may produce a list, but it may not distinguish engineering structure from manufacturing structure or preserve revision control.

    An EBOM, or engineering bill of material, describes the product from a design perspective. An MBOM, or manufacturing bill of material, describes how the product is assembled or produced. They are related but are not interchangeable. A spreadsheet that creates one flat list may be insufficient for both engineering and manufacturing.

    Pricing and margin errors

    When cost and price logic are separated from configuration logic, a technically valid product may still be priced incorrectly. For example, changing a pump material may affect purchased cost, machining cost, lead time and selling price. A simple option surcharge may not capture all of these effects.

    Weak traceability

    Manufacturers need to know which product rules, component revisions and prices were used for a quote or order. File timestamps and email history are not a complete product configuration audit trail. Traceability matters when a customer changes a requirement, a supplier component is substituted or a warranty issue is investigated.

    Key-person dependency

    If only one application engineer understands the workbook, that person becomes the de facto owner of the product model. Absence, retirement or reassignment can create a serious operational dependency.

    Security and uncontrolled changes

    Cell protection and file permissions can reduce accidental edits, but they do not provide the same governance as a controlled application with role-based access, managed releases, testing and change approval. Macros can also introduce security and deployment concerns.

    Where manufacturing CPQ fits

    Manufacturing CPQ is software used to configure complex products, calculate prices and costs, generate quotes and, depending on the platform, create engineering or production outputs. It is broader than generic sales CPQ because the configured result may include technical specifications, calculations, BOMs, CAD files and ERP order data.

    A typical flow may look like this:

    1. A salesperson, dealer or engineer enters customer requirements.
    2. The product model presents valid options and applies dependencies and constraints.
    3. Technical calculations determine dimensions, capacity, performance or component ratings.
    4. The system calculates cost and selling price using approved commercial rules.
    5. The configuration produces a quote and customer-facing specification.
    6. The system generates a configurable BOM or sends structured selections to engineering and production systems.
    7. Where supported, CAD automation creates product-specific models, drawings or documentation.
    8. An approved configuration is transferred to enterprise systems for order, planning and manufacturing execution.

    Not every CPQ platform supports every step. Some products focus on guided selling and quoting. Others provide deeper product modeling, BOM generation, CAD automation or engineering calculations. Buyers should verify each capability rather than assuming that the term CPQ guarantees a complete engineering-to-production workflow.

    Relevant system relationships are described in the CPQ integrations guide. Customer and opportunity data may come from a CRM system, or customer relationship management system. Product lifecycle data may be maintained in a PLM system, meaning product lifecycle management, or a PDM system, meaning product data management. The ERP system, or enterprise resource planning system, may manage item masters, inventory, purchasing, orders and production planning. CAD means computer-aided design; MES means manufacturing execution system; PIM means product information management. These systems have different responsibilities and should not be treated as interchangeable.

    What should replace a spreadsheet?

    The right replacement depends on the product and process. A manufacturer does not always need a full CPQ platform. The options below address different levels of complexity.

    Situation Possible next step Important consideration
    Simple product, few variants, low risk Controlled spreadsheet or lightweight application Define ownership, version control and validation
    Many options and dependencies, limited engineering output Product configuration or rules engine Model features, constraints and product data centrally
    Configuration affects price, quote and BOM Manufacturing CPQ Verify configurable BOM, costing and ERP integration
    Configuration creates drawings or designs CPQ with CAD or engineering automation Verify supported CAD systems, templates and revision workflow
    Every order is substantially unique ETO workflow with engineering controls, possibly supported by CPQ Do not force all engineering judgment into fixed options

    The objective is not to eliminate engineering judgment. It is to automate repeatable decisions and reserve expert effort for exceptions, new designs and non-standard requirements.

    How to decide whether your spreadsheet has reached its limit

    Assess the workbook against the following questions:

    • Can the business identify one owner for every product rule, price, component and calculation?
    • Can a new user configure a product without relying on informal instructions?
    • Can the system prevent invalid combinations rather than merely display warnings?
    • Can the company reproduce the exact configuration used for an old quote?
    • Can a product revision be released and tested without editing several unrelated files?
    • Can the configured result produce the correct customer specification and internal item references?
    • Can the process distinguish EBOM, MBOM, purchased items, labor and documentation?
    • Can pricing changes be approved and audited?
    • Can the process exchange structured data with ERP, CRM, PLM, PDM, CAD or MES systems where necessary?
    • Can the organization measure how often engineering corrects sales configurations?

    If several answers are no, the spreadsheet is likely carrying more operational responsibility than it can safely support.

    Moving from Excel to a controlled product model

    1. Map the current process before selecting software

    Document how a requirement becomes a quote, configuration, engineering package, order and production record. Include exceptions, approvals, manual calculations, copied data and points where users consult separate files.

    The CPQ implementation guide covers requirements, architecture, migration, testing, governance and adoption. These activities should begin before a software demonstration, because a product with impressive interface features may still be unsuitable for the company’s product logic or data ownership model.

    2. Separate data from logic

    Identify which information is a stable product attribute and which information is a rule. For a pump, motor power, material grade, connection size and seal type may be data values. A rule may state that a selected seal is unavailable for a particular fluid or temperature range.

    Separating data from logic makes updates easier and reduces the need to rewrite formulas when prices, suppliers or component attributes change.

    3. Define authoritative ownership

    Decide which system owns each category of information. Product lifecycle data may belong in PLM, transactional item and order data in ERP, customer and opportunity data in CRM, and configuration logic in the CPQ or product configuration layer. In practice, ownership varies by architecture, so it must be documented rather than assumed.

    4. Start with a representative product family

    Do not select only the easiest product. Choose a product family that demonstrates the real complexity: technical dependencies, calculations, optional accessories, pricing variation, BOM structure and a meaningful engineering handoff. At the same time, avoid beginning with every product and every legacy workbook.

    5. Convert spreadsheet logic into testable rules

    Extract formulas, lookup tables, macros, warnings and manual instructions. Rewrite them as explicit requirements such as:

    • If the operating temperature exceeds a defined limit, restrict the material choices to approved grades.
    • If the selected actuator torque exceeds the standard range, require the next actuator class.
    • If the enclosure is certified for a hazardous location, allow only compatible electrical components.
    • If the product includes a second circuit, add the required fittings, controls and documentation to the BOM.

    Each rule should have an owner, a reason, a test case and a defined response when the condition is not met.

    6. Test combinations, not just individual options

    Testing only one valid example is not enough. Test boundary values, incompatible options, missing inputs, substitutions, obsolete components, currency changes, revisions and unusual but valid configurations. Include both technical validation and the downstream output: price, specification, BOM, drawing and ERP transaction where applicable.

    7. Plan coexistence during transition

    Most manufacturers will operate spreadsheets and the new system together for a period. Define which process is authoritative during the transition. If users can freely choose between the old workbook and new application, the organization may create two competing product models.

    Limitations and cases where Excel may remain appropriate

    Excel is not automatically a poor tool. It may remain appropriate when the product has few options, the configuration volume is low, the consequences of an error are limited and one accountable team controls the workbook. It can also be valuable for exploratory engineering calculations, scenario analysis, data cleansing and temporary migration work.

    Excel may be the wrong tool when:

    • the product has many interacting options and technical constraints;
    • multiple departments or dealers configure the same product;
    • quotes must produce manufacturing-ready data;
    • prices, costs or supplier data change frequently;
    • the business needs auditability and revision control;
    • configuration must connect to ERP, PLM, CAD or other systems;
    • engineering effort is being consumed by checking routine selections;
    • the business cannot identify which workbook is authoritative.

    A new CPQ system also has limitations. It requires product-model analysis, data cleanup, rule ownership, testing, integration work and ongoing governance. Poorly modeled CPQ can simply turn spreadsheet complexity into application complexity. A manufacturer should therefore improve the product data and decision model, not only migrate cells into a new interface.

    Relationship to CTO, ETO, MTO and ATO workflows

    Configure-to-Order (CTO) means selecting and assembling a product from predefined options. Assemble-to-Order (ATO) generally uses stocked or planned subassemblies that are combined after an order. Make-to-Order (MTO) produces a product or components in response to an order. Engineer-to-Order (ETO) requires new or substantially adapted engineering for the customer.

    Spreadsheets often blur these models. A product presented as standard CTO may actually require engineering review because the configuration rules are incomplete. Conversely, a well-modeled CPQ process can automate standard CTO choices while routing genuine ETO exceptions to engineering.

    The manufacturing workflows guide explains how configuration connects sales, engineering, planning and production across these models.

    Practical example: configurable industrial pump packages

    Consider a pump package configured from flow rate, pressure, fluid type, temperature, pump material, seal arrangement, motor rating, control panel, base frame and connection standard.

    A basic spreadsheet may look up a pump price and add surcharges for stainless steel and a variable-frequency drive. A controlled product model must do more:

    • validate that the selected pump curve satisfies the flow and pressure requirements;
    • restrict seal materials based on fluid and temperature;
    • select a compatible motor and electrical enclosure;
    • calculate or retrieve the correct base-frame dimensions;
    • select fittings, guards, couplings and instrumentation;
    • calculate cost and selling price using approved rules;
    • create the correct configurable BOM;
    • produce a technical specification and, where supported, a drawing or CAD variant;
    • send approved item and configuration data to ERP and engineering systems.

    Excel may support parts of this process, but once the same decisions must be made consistently by sales, application engineering, dealers and production, a governed configuration architecture becomes more valuable than another larger workbook.

    Conclusion

    Excel stops working for product configuration when its weaknesses in control, traceability, rule maintenance and system integration create more risk than its flexibility provides. The trigger is not a specific number of rows or options. It is the growing need to make repeatable technical and commercial decisions and carry them accurately into engineering and production.

    Manufacturers should first map the product logic and workflow, identify the authoritative data sources, separate standard configuration from genuine ETO work and test the downstream outputs. A product configuration system or manufacturing CPQ platform may then replace the spreadsheet functions that require controlled rules, pricing, BOM generation, CAD automation or enterprise integration.

    For a broader introduction, see the guide to manufacturing CPQ. For related evaluation criteria, review the guides to BOM, pricing and quoting, CAD and engineering automation and manufacturing CPQ comparisons.

    Semantic map

    The article connects spreadsheet limitations with product configuration, engineering control and manufacturing data flows:

    • Spreadsheets store product data and formulas.
    • Product configuration models options, dependencies and constraints.
    • Configuration rules prevent invalid combinations.
    • Engineering calculations derive technical values from requirements.
    • Configured products generate customer specifications and, where supported, BOMs.
    • EBOM and MBOM represent different engineering and manufacturing structures.
    • CPQ calculates costs, prices and quote outputs.
    • CAD automation generates product-specific models or drawings when supported.
    • ERP manages transactional, item and order data.
    • PLM and PDM manage product and design information.
    • CTO uses predefined valid configurations.
    • ETO routes non-standard requirements to engineering.

    Frequently asked questions

    1. Is Excel always unsuitable for product configuration?

    No. Excel can be suitable for simple products, low volumes, exploratory calculations and controlled specialist work. It becomes unsuitable when configuration logic, revisions, users and downstream manufacturing outputs require stronger control.

    2. What is the clearest sign that a spreadsheet has become a configuration risk?

    The clearest sign is that different people use different workbook versions or manually interpret the same product rules. Repeated corrections by engineering and inconsistent BOMs are also strong indicators.

    3. Can Excel enforce product configuration rules?

    Excel can enforce some rules using validation, formulas and macros. However, complex rules become difficult to inspect, test, govern and maintain, especially when they are distributed across multiple worksheets and files.

    4. When should a manufacturer consider CPQ?

    Consider manufacturing CPQ when product choices affect technical validity, price, cost, BOMs, drawings, approvals or ERP transactions and the company needs those decisions to be repeatable and traceable.

    5. Does CPQ automatically replace engineering?

    No. CPQ can automate repeatable configuration and calculations, but genuine ETO work still requires engineering judgment, design review and controlled release processes.

    6. Can a CPQ system generate a BOM?

    Some CPQ platforms can generate configurable BOMs or pass structured configuration data to another system. This is not universal, so buyers should verify BOM structure, revision behavior, EBOM and MBOM support and ERP integration.

    7. What is the difference between a configured BOM and a spreadsheet parts list?

    A configured BOM is normally derived from a controlled product model and can represent component relationships, quantities, revisions and variant logic. A spreadsheet parts list may be accurate, but it does not automatically provide those controls.

    8. Should prices remain in Excel while configuration moves to CPQ?

    That can be a temporary transition arrangement, but it creates a synchronization risk. The long-term design should define which system owns costs, prices, discounts, surcharges and approval rules.

    9. Can a rules engine handle engineering calculations?

    Some platforms support calculations, while others rely on external engineering services or integrations. The required formulas, units, tolerances, certification rules and validation behavior should be tested with representative products.

    10. Is guided selling the same as product configuration?

    No. Guided selling asks business-oriented questions to narrow choices or recommend a product. Product configuration validates the selected product and its technical relationships. A manufacturing process may use both.

    11. What systems commonly connect to manufacturing CPQ?

    Depending on the architecture, CPQ may connect to CRM, ERP, PLM, PDM, CAD, PIM, MES, ecommerce and external engineering services. The exact integration capability varies by platform and implementation.

    12. How does spreadsheet configuration affect ERP data?

    It often causes manual re-entry of item numbers, quantities, prices and configuration details. This can create differences between the quoted product and the ERP order unless the transfer is controlled and validated.

    13. Can a spreadsheet produce CAD drawings?

    A spreadsheet may provide parameters to a separate CAD process, but it is not normally a CAD automation system. CAD automation requires templates, parameter mapping, validation and document or revision management.

    14. When is a spreadsheet acceptable for an ETO business?

    It may be acceptable for early requirement capture or engineering analysis. It is less suitable as the authoritative product definition when each project requires controlled design revisions, approvals, BOMs and production documentation.

    15. How should a company migrate spreadsheet rules?

    Inventory the workbooks, identify authoritative data, extract formulas and manual instructions, rewrite them as explicit rules, assign owners and test valid and invalid scenarios before deploying the new model.

    16. Should a manufacturer migrate every product at once?

    Usually not. A representative product family is a better starting point. It should contain enough technical and commercial complexity to test the architecture without making the first release unmanageable.

    17. What should be tested after replacing Excel?

    Test option validation, boundary values, calculations, prices, discounts, revisions, substitutions, BOMs, customer documents, engineering outputs and transfers to connected systems. Test both normal and exceptional configurations.

    18. What is the biggest implementation mistake?

    A common mistake is copying spreadsheet structure directly into a new application without clarifying data ownership, product rules, workflow responsibilities and downstream requirements. The goal is a maintainable product model, not merely a new user interface.

  • Composable CPQ for Manufacturing

    Composable CPQ for manufacturing is an architecture in which configure, price, quote (CPQ) capabilities are delivered as modular services and connected to the wider manufacturing technology stack. Instead of treating CPQ as one isolated application, a composable approach separates product configuration, rules, engineering calculations, pricing, quoting, bill of materials (BOM) generation, computer-aided design (CAD) automation and integration services where appropriate.

    This matters for manufacturers because the information required to produce an accurate quote is rarely owned by one system. Product definitions may be maintained in product lifecycle management (PLM) or product data management (PDM) software, customer and opportunity information may be held in customer relationship management (CRM), costs and item masters may belong to enterprise resource planning (ERP), and drawings or models may be generated by CAD systems. A composable CPQ architecture coordinates these capabilities while preserving data ownership in the systems responsible for it.

    In practical terms, composable CPQ can help a manufacturer configure a valid pump package, calculate a suitable motor and impeller combination, price the resulting assembly, generate a configurable BOM, request a CAD drawing, and send an approved order to ERP. However, not every CPQ platform provides every one of these functions. Buyers must establish which capabilities are native, which are delivered by extensions, and which remain in ERP, PLM, CAD or engineering applications.

    For background, see the broader guide to CPQ software for manufacturing and the guide to CPQ integrations.

    What is composable CPQ?

    Composable CPQ is a modular approach to CPQ in which business capabilities are exposed through reusable applications, services, APIs and data contracts. A manufacturer can combine these components to support a specific workflow rather than adopting one monolithic application for every configuration and engineering task.

    A composable architecture may include the following components:

    • Configuration experience: the user interface used by a salesperson, dealer, engineer, customer or ecommerce buyer.
    • Product model: the representation of products, options, variants, attributes, dependencies and selectable values.
    • Rules engine: logic that validates combinations, derives selections, enforces constraints or determines required actions.
    • Engineering calculation service: formulas or external engineering applications that calculate dimensions, capacity, performance or component selection.
    • Pricing and costing service: logic for list prices, discounts, surcharges, costs, margins, currencies and commercial approvals.
    • BOM service: logic that produces a configurable, engineering or manufacturing bill of materials for the selected product.
    • CAD and visualization service: tools that generate models, drawings, images or product-specific representations when supported.
    • Quote and document service: generation of quotations, specifications, approval records and customer-facing documents.
    • Integration and orchestration layer: APIs, events, middleware and workflow services that exchange data with ERP, CRM, PLM, PDM, CAD, product information management (PIM) and manufacturing execution system (MES) applications.

    These components can be deployed in one product, several products or a mixture of packaged software and custom services. “Composable” describes the architecture and assembly model; it does not guarantee that an implementation will be simple or that every component will be interchangeable.

    Why composable CPQ is relevant to manufacturers

    Generic sales CPQ often focuses on selecting commercial options, applying discounts and producing a quote. Manufacturing CPQ must frequently go further. The configuration may determine engineering feasibility, component dimensions, material requirements, production operations, compliance documentation and the data needed to manufacture the order.

    For example, configuring an industrial air-handling unit may involve airflow, static pressure, cabinet dimensions, insulation, coil selection, fan type, motor power, electrical supply, controls and environmental conditions. A valid configuration may require engineering calculations and may produce different components, drawings and production instructions. The pricing result is only one output of the configuration.

    Composable architecture is useful where a business has already invested in specialized systems or where different product families require different levels of engineering automation. One product line may need a deep CAD automation workflow, while another may only need rules-based option validation and ERP pricing. A modular design can support both without forcing every product family into the same technical model.

    Composable CPQ architecture in the manufacturing stack

    A typical architecture has several layers. The exact boundaries vary by business and software selection, but the following model helps clarify responsibilities.

    Layer Typical responsibility Manufacturing example
    Experience Guides a user through configuration, pricing and quoting Dealer selects a pump duty, materials, motor and accessories
    Configuration Maintains product options, attributes, dependencies and validation Prevents an incompatible motor and voltage combination
    Engineering Calculates or selects technical values and design outputs Calculates pump head, flow, shaft power or heat exchanger size
    Commercial Calculates prices, costs, discounts, margins and approvals Applies material surcharges and customer-specific discount rules
    Output generation Creates BOMs, specifications, drawings and quote documents Produces an order-specific BOM and a dimensioned arrangement drawing
    Enterprise systems Owns customer, item, cost, order, revision and production data ERP receives the approved order and manufacturing item references
    Integration Moves data between services and systems API or event sends configuration, price and revision information to ERP and PLM

    Configuration and product models

    The product model describes what can be sold and how it can be combined. It may include product families, models, features, options, dimensions, materials, accessories, software selections and service levels.

    The model should not be confused with a price list. A product configuration defines a technically and commercially meaningful product instance. Pricing is a separate concern, even though the selected configuration supplies inputs to pricing.

    Manufacturers should also distinguish several types of rules:

    • Rules-based configuration: explicit logic such as “if 480 V is selected, require a compatible motor option.”
    • Constraint-based configuration: a solver or constraint model determines whether a set of values satisfies technical relationships, ranges or dependencies.
    • Guided selling: questions and recommendations help a user reach a suitable product, but guided selling alone does not prove engineering validity.

    More detail on product models, dependencies and constraints is available in the guide to product configuration.

    Engineering and CAD services

    Some manufacturing CPQ implementations include engineering calculations, parametric design automation, 2D drawings, 3D visualization or CAD file generation. Others validate configuration and hand the selected parameters to a separate engineering system.

    For example, a configurable conveyor may use CPQ to capture length, width, belt type, elevation, motor choice and guarding. A calculation service can determine drive requirements, while a CAD system generates a layout and an engineering application creates a product-specific drawing. The CPQ layer should record the inputs, calculation version and output references so that the quote can be traced to a particular engineering result.

    CAD automation is not an automatic consequence of composable CPQ. It requires suitable parametric models, stable interfaces, engineering rules, template governance and a process for handling exceptions. See CAD and engineering automation for CPQ.

    Pricing, costing and quoting

    A pricing service may calculate a selling price from the configured product, customer segment, currency, region, delivery terms, quantity, discount authority and commercial policies. A costing service may calculate material, labor, subcontracting, freight or estimated manufacturing costs.

    These are not necessarily the same as the configuration rules. A material may be technically valid but subject to a surcharge. A custom dimension may be valid but require engineering review. A customer may receive a discount that does not change the product definition but does change the commercial offer.

    Quote documents should identify the configuration, revision, assumptions, exclusions, lead-time basis and approval status. For BOM, pricing and quote architecture, see BOM generation, pricing and quote automation.

    Data ownership in a composable CPQ architecture

    The most important architecture decision is not whether to use APIs. It is deciding which system owns each type of data and how other systems consume it.

    Data domain Possible system of record CPQ relationship
    Customer, account and opportunity CRM CPQ reads customer context and returns configuration, quote and status information
    Product lifecycle, revisions and approved product structures PLM or PDM CPQ consumes released definitions, options, revisions or engineering references
    Item master, inventory, costs, orders and financial data ERP CPQ retrieves item and cost data and sends approved order information
    Product attributes and commercial content PIM or product master CPQ uses descriptions, images, documents and channel-specific content
    Geometry, templates and drawings CAD or engineering system CPQ sends parameters and stores generated-file references
    Production execution and work-center status MES CPQ usually provides order or configuration context rather than replacing execution control
    Configuration session and quote state CPQ CPQ records selected options, rule results, calculated values and commercial outcomes

    There is no universal answer for every domain. Some organizations manage configurable BOM logic in CPQ, while others maintain it in PLM or ERP. The decision should consider revision control, engineering approval, reuse, performance, auditability and the needs of downstream production.

    How a composable CPQ workflow works

    1. Start with commercial or customer context. A salesperson opens a CRM opportunity, or a dealer starts a new configuration. Customer, location, currency and channel data are passed to CPQ.
    2. Load the relevant product model. CPQ retrieves the applicable product family, market rules, effective date and product revision.
    3. Capture requirements. The user enters technical requirements such as flow, pressure, capacity, dimensions, temperature, material, voltage or environmental conditions.
    4. Validate and derive selections. Rules prevent invalid combinations, while calculations or selection services determine compatible components.
    5. Request engineering outputs when needed. CPQ may call a calculation engine, CAD automation service or engineering workflow. If the configuration exceeds supported rules, it can create an engineering review task.
    6. Generate commercial results. Pricing and costing services calculate price, margin, lead-time assumptions and approval requirements.
    7. Generate manufacturing-related outputs. Depending on the architecture, the system creates a configurable BOM, an engineering BOM (EBOM), a manufacturing BOM (MBOM), drawings, specifications or references to these outputs.
    8. Produce and approve the quote. The customer-facing quote includes the selected configuration and relevant assumptions. Internal approvals are recorded before release.
    9. Transfer the approved result. CPQ sends an order, configured item, BOM reference, document reference or configuration payload to ERP, PLM, PDM or another downstream system.
    10. Retain traceability. The business should be able to identify which product model, rule version, price version and engineering output produced the quote.

    This workflow can support configure-to-order (CTO), assemble-to-order (ATO), make-to-order (MTO) and engineer-to-order (ETO), but the level of automation differs. CTO uses predefined configurations. ATO assembles stocked or semi-finished components. MTO produces a product after the order, often using established designs. ETO creates or modifies engineering outputs for the specific order and normally requires stronger engineering workflow integration.

    The differences between these operating models are discussed in manufacturing CPQ workflows.

    Configurable BOMs, EBOMs and MBOMs

    A BOM is a structured list of components and quantities required for a product or assembly. A configurable BOM represents possible components and selection conditions. An EBOM is an engineering bill of materials organized around design intent. An MBOM is a manufacturing bill of materials organized around how the product is assembled or produced.

    Composable CPQ may generate a configured BOM directly, select an approved BOM variant, or send configuration parameters to PLM or ERP for BOM resolution. These approaches have different governance implications.

    Approach Potential use Important question
    CPQ resolves configured components Fast CTO or ATO quoting with established options How are revisions and production changes synchronized?
    PLM resolves the EBOM Engineering-controlled products with formal lifecycle management Can CPQ consume only released and valid structures?
    ERP resolves the production BOM Organizations where ERP owns item and manufacturing structures Can the order retain the original configuration and rule version?
    CPQ sends parameters to an engineering workflow ETO or calculation-driven products How are exceptions, approvals and design changes tracked?

    A common implementation error is treating any list of selected options as a production-ready MBOM. A commercial configuration may omit phantom assemblies, operation sequences, alternate materials, scrap factors, work instructions or plant-specific manufacturing data. The receiving system must confirm whether the output is suitable for production or only for quotation and engineering review.

    Integration patterns for composable CPQ

    Synchronous APIs

    A synchronous API request returns a result during the configuration session. It is suitable for retrieving item attributes, validating a selection, calculating a price or checking a technical value when the response is expected quickly.

    For example, CPQ may send pump flow, head, fluid and temperature to a selection service and receive compatible pump models. Timeouts, error handling and fallback behavior are important because a slow or unavailable service can interrupt quoting.

    Asynchronous events and workflows

    Asynchronous integration is useful when an operation takes longer or requires human review. CAD generation, ETO engineering, supplier checks and formal approval can produce events such as “drawing generated,” “engineering review completed” or “quote approved.”

    Event-based designs require reliable message handling, correlation identifiers, retries, duplicate protection and clear ownership of status. A quote should not appear technically approved simply because an integration request was sent.

    Batch and scheduled synchronization

    Some data does not need real-time exchange. Product descriptions, price books, released items, costs and document metadata may be synchronized on a schedule. Batch synchronization can reduce integration complexity but introduces timing and effective-date risks.

    Headless configuration services

    A headless configuration service separates configuration logic from the user interface. The same product model can support a salesperson application, dealer portal, ecommerce front end or internal engineering tool. This approach is useful when several channels need consistent rules, but it requires a stable API and careful control of channel-specific behavior.

    Benefits and limitations

    Potential benefits

    • Reuse of existing systems: the business can retain specialized ERP, PLM, CAD or engineering applications rather than replacing every system.
    • Channel consistency: shared configuration services can apply the same product rules across sales, dealers and digital channels.
    • Incremental delivery: a manufacturer can begin with configuration and pricing, then add BOM, engineering or CAD services where the business case is clear.
    • Clearer ownership: explicit boundaries can reduce duplicate product, cost and revision data.
    • Product-family flexibility: different product lines can use different engineering depth while sharing commercial and integration services.
    • Better traceability: versioned services and data references can make it easier to understand how a quote was produced.

    Limitations and risks

    • Integration becomes a product of its own: multiple services require monitoring, version management, security, testing and operational support.
    • Data semantics may conflict: an “option,” “variant,” “item,” “assembly” or “revision” may mean different things in CPQ, ERP and PLM.
    • Distributed failures are harder to diagnose: a quote may depend on several services with different availability and response times.
    • Rule duplication can grow: copying the same compatibility logic into CPQ, ERP, PLM and CAD creates inconsistent behavior.
    • Transaction boundaries are complex: a quote, drawing and order may not be committed at the same time.
    • Composable does not mean low-code: sophisticated configuration and engineering models still require domain expertise, testing and governance.
    • Vendor boundaries may be unclear: a platform may advertise extensibility or APIs without providing the manufacturing capabilities needed for BOM, CAD or engineering automation.

    Implementation considerations

    Define the target workflow before selecting components

    Start with a specific product family and workflow. Document the inputs, rules, calculations, outputs, approvals and systems involved. A pump manufacturer might map the flow from duty-point entry through pump selection, motor validation, material selection, costing, drawing generation and ERP order creation.

    Assign ownership for every important data object

    Create a data ownership matrix for product options, rules, revisions, item numbers, costs, prices, BOM structures, CAD templates, documents and customer data. Identify who can change each object, how changes are approved and how effective dates are applied.

    Separate rules by purpose

    Keep commercial rules, technical constraints, engineering formulas and manufacturing transformations distinguishable. A rule that blocks a combination is not the same as a formula that calculates a dimension, and neither is the same as a discount condition.

    Version models and outputs

    Configuration results should identify the product model version, rule version, price book, calculation version and relevant engineering revision. Without this information, reproducing an old quote or explaining a changed result becomes difficult.

    Design for exceptions

    Not every product can be fully automated. The architecture should support engineering review, manual adjustments, substitutions, customer-specific requirements and incomplete data without silently creating an invalid result. An ETO request should have a visible status and a defined handoff rather than appearing as a normal CTO configuration.

    Test the complete chain

    Testing must cover more than the CPQ user interface. Use representative combinations and test configuration validation, calculations, prices, BOM resolution, CAD outputs, document generation, API failures, revisions, permissions and downstream order creation. Regression tests are particularly important when a shared product model supports several channels.

    Implementation planning, governance and testing are covered in the CPQ implementation guide.

    How to evaluate composable CPQ software

    Manufacturers should evaluate the architecture against actual product and workflow requirements rather than counting generic features. Important questions include:

    • Can the platform represent product families, variants, dimensions, ranges, dependencies and conditional options?
    • Does it support rules-based configuration, constraint solving, guided selling, or only simple option selection?
    • Can rules and product models be versioned, tested and maintained by appropriate business or engineering users?
    • Can it expose configuration, validation, pricing and quote functions through documented APIs?
    • Does it generate a BOM, select a BOM, or pass parameters to another BOM-owning system?
    • Can it distinguish commercial configuration from EBOM and MBOM requirements?
    • Does it support engineering calculations, CAD automation or 3D visualization natively, through extensions, or not at all?
    • How are ERP, CRM, PLM, PDM, CAD, PIM and MES integrations implemented and monitored?
    • Can it support dealer, distributor, ecommerce and internal engineering channels with consistent logic?
    • How are ETO exceptions, approvals, manual engineering work and document revisions handled?
    • What happens when an external system is unavailable during configuration or order submission?
    • Can the organization export its product model, rules, configuration history and outputs if the architecture changes?

    Vendor claims should be verified through documentation, demonstrations using the manufacturer’s own product examples, API specifications, implementation references where available and a proof of concept. Do not assume that an API or modular architecture includes manufacturing-grade configuration, BOM, CAD or engineering behavior.

    Semantic map

    The following relationships summarize the main entities and how they interact in a composable manufacturing CPQ architecture.

    • CPQ connects product configuration with pricing, quoting and downstream manufacturing data.
    • Product models define selectable features, options, attributes and variants.
    • Configuration rules prevent invalid product combinations.
    • Constraint-based configuration evaluates technical relationships and limits.
    • Engineering calculations transform customer requirements into technical selections or values.
    • Configured products provide inputs to pricing and costing services.
    • Configured products can generate or select configurable BOM structures.
    • EBOM represents engineering design intent.
    • MBOM represents manufacturing assembly and production structure.
    • CAD automation generates product-specific models or drawings when supported.
    • CRM provides customer and opportunity context to CPQ.
    • ERP owns or consumes item, cost, order and financial data.
    • PLM or PDM governs product revisions and released engineering data.
    • MES executes or monitors production activities after order release.
    • APIs and events exchange configuration and engineering data between systems.
    • ETO workflows route unsupported configurations to engineering review.

    Frequently asked questions

    What is composable CPQ for manufacturing?

    It is a modular CPQ architecture that combines configuration, rules, engineering, pricing, quoting and manufacturing data services with systems such as ERP, PLM, CRM, CAD and MES.

    How is composable CPQ different from generic sales CPQ?

    Generic sales CPQ may focus on options, discounts and quote documents. Manufacturing composable CPQ also considers technical constraints, engineering calculations, BOMs, CAD outputs, revisions and production handoffs where those capabilities are required.

    Does composable CPQ replace ERP?

    Usually not. ERP commonly remains responsible for items, inventory, costs, orders, financial processing and manufacturing-related master data. CPQ supplies a validated commercial and technical configuration to ERP.

    Does composable CPQ replace PLM?

    Usually not. PLM often manages product lifecycle, engineering revisions and released product structures. CPQ may consume PLM data or manage a commercial configuration model linked to PLM references.

    Can composable CPQ generate a manufacturing BOM?

    It can in some implementations, but this is not universal. The BOM may instead be resolved in ERP or PLM. Buyers should verify whether the output is a configurable BOM, EBOM, MBOM or only a list of quoted options.

    What is the role of CAD in composable CPQ?

    CAD can receive configuration parameters and generate product-specific models, drawings or layouts. This requires compatible parametric models, automation interfaces and engineering governance; it is not guaranteed by a CPQ platform.

    Can composable CPQ support engineer-to-order products?

    Yes, when it includes or integrates with engineering workflow, calculation, CAD, approval and document processes. ETO should be treated as a controlled exception or design workflow rather than as simple option selection.

    Is a headless CPQ the same as composable CPQ?

    No. Headless CPQ separates the configuration service from its user interface. Composable CPQ is a broader architectural approach that may include headless services, modular applications, APIs and external engineering or enterprise systems.

    What systems commonly integrate with composable CPQ?

    Common systems include CRM, ERP, PLM, PDM, CAD, PIM, MES, ecommerce platforms, calculation services, document systems and integration middleware. The exact integration depends on the manufacturer’s workflow.

    Where should product rules be maintained?

    Rules should be maintained by the system best suited to their purpose and governance. Configuration rules may reside in CPQ, lifecycle-controlled engineering rules may reside in PLM or an engineering service, and manufacturing transformations may belong in ERP or manufacturing applications.

    How does composable CPQ handle pricing?

    It uses the configured product and commercial context as inputs to price books, cost data, discounts, surcharges, currencies, margins and approval policies. Pricing logic should remain distinguishable from technical configuration rules.

    Can one composable CPQ model serve dealers and internal engineers?

    It can when the platform provides reusable configuration services and role-specific interfaces. The dealer may see guided questions and prices, while an engineer may see calculated values, rule diagnostics and design outputs.

    What happens when an external integration fails?

    The system should provide explicit error states, retries where appropriate, monitoring and a controlled fallback or review process. It should not silently issue a technically incomplete quote or order.

    How does composable CPQ support configure-to-order?

    It validates a predefined product model, selects compatible options, calculates price and produces the required order or BOM data. The amount of downstream automation depends on ERP, PLM and production integration.

    How does composable CPQ support make-to-order?

    It captures the customer-specific requirements and creates a valid order configuration, while ERP or engineering systems determine procurement, production and delivery details.

    What is the main implementation risk?

    A major risk is unclear ownership or duplicated logic across CPQ, ERP, PLM, CAD and engineering services. This can produce conflicting rules, incorrect revisions, unreliable BOMs and difficult troubleshooting.

    How should a manufacturer start a composable CPQ project?

    Start with one representative product family and map the complete workflow from requirements through quote, engineering output and order release. Define data ownership, interfaces, exception handling and measurable acceptance criteria before expanding.

    How should composable CPQ vendors be evaluated?

    Evaluate product-model depth, rules, APIs, versioning, BOM behavior, pricing, engineering and CAD integration, ERP and PLM connectivity, exception workflows, governance, security, testing and implementation effort using real manufacturing examples.

  • Option Dependencies in Complex Product Configuration

    Option dependencies are relationships between configurable product choices. They determine whether options are compatible, required, excluded, conditionally available or automatically added when a user selects another option. In manufacturing Configure, Price, Quote (CPQ), these dependencies are used to validate products such as industrial machines, pumps, HVAC units, electrical assemblies and specialty vehicles before a quote reaches engineering or production.

    A manufacturing CPQ configurator does more than display a list of features. It applies product rules to dimensions, materials, performance requirements, components, manufacturing methods and commercial choices. For example, selecting a high-temperature pump seal may require a particular shaft material, exclude a standard elastomer and change the allowable operating range. The result may affect the configurable bill of materials (BOM), engineering calculations, cost, price, drawings and the manufacturing workflow.

    This guide explains how option dependencies work, how they are represented in a product model, how they differ from related rule types, and how manufacturers can implement them without creating an unmaintainable collection of exceptions.

    What are option dependencies?

    An option dependency is a rule that defines a relationship between two or more product options, attributes or configuration decisions. The relationship may require an option, prohibit a combination, suggest a choice, change a value or trigger an additional component.

    In a simple example, a pump product may contain these options:

    • Pump size: 50 mm, 80 mm or 100 mm
    • Impeller material: cast iron, stainless steel or duplex stainless steel
    • Motor type: standard efficiency or high efficiency
    • Seal package: standard, chemical-duty or high-temperature
    • Control panel: none, local starter or variable frequency drive

    The product model can express dependencies such as:

    • If the chemical-duty seal is selected, stainless steel or duplex wetted parts are required.
    • If the high-temperature seal is selected, the maximum operating temperature must be within the seal rating.
    • If a variable frequency drive is selected, a compatible motor and control enclosure are required.
    • If the 100 mm pump size is selected, the standard motor option is unavailable because the required power exceeds its rating.
    • If the pump is configured for a hazardous location, the control panel and motor certifications must be compatible.

    These are not merely sales recommendations. They can represent engineering constraints, safety requirements, manufacturing choices, compliance requirements or commercial policies.

    Why option dependencies matter in manufacturing CPQ

    Generic sales CPQ may use dependencies to control product bundles or pricing. Manufacturing CPQ typically needs a deeper model. A valid configuration must often be physically buildable, technically safe, serviceable, costed correctly and transferable to downstream systems.

    An invalid combination can create several problems:

    • Sales quotes a product that cannot meet the customer specification.
    • Engineering must manually correct the configuration after order entry.
    • The generated BOM contains incompatible or missing components.
    • A computer-aided design (CAD) model or drawing uses the wrong dimensions.
    • Material, motor, voltage or pressure selections violate product limits.
    • Cost and price are calculated from the wrong product variant.
    • Enterprise resource planning (ERP) receives an incomplete or incorrect manufacturing structure.

    Dependencies move validation closer to the point where the product is specified. They do not eliminate engineering review in every case, particularly for engineer-to-order work, but they reduce avoidable errors and make the handoff more structured.

    See the product configuration guide for a broader explanation of product models, features, options, constraints and validation.

    Core types of option dependencies

    Requires dependencies

    A requires rule states that selecting one option requires another option, value or component. For example, selecting a 400-volt three-phase motor may require a control panel rated for that electrical configuration.

    Requires rules can apply to visible selections or hidden product data. A customer may select a high-pressure option, while the product model automatically requires a reinforced casing, a particular gasket material and a higher-rated fastener set.

    Excludes dependencies

    An excludes rule prevents two options from being selected together. A standard aluminum housing may be excluded when a corrosive chemical application is selected. A manual control system may be excluded when a fully automated safety package is required.

    Exclusions should be used for genuine incompatibilities. Overusing them to hide uncertain or poorly documented product knowledge can make the model difficult to understand and maintain.

    One-of and mutually exclusive dependencies

    Some option groups allow exactly one choice. A machine may require one drive type: hydraulic, electric or pneumatic. Other groups may allow several choices but prevent particular pairs. For example, a vehicle may allow several accessory packages but exclude two packages that occupy the same mounting location.

    At-least-one and conditional-required dependencies

    An at-least-one rule requires a selection from a group. A machine may require at least one discharge connection, communication protocol or safety device. A conditional-required rule applies only in a specific context. For example, a remote monitoring module may be required if the customer selects a cloud-connected service, but not for a locally controlled machine.

    Value and range dependencies

    Some relationships concern numeric or dimensional values rather than discrete options. A conveyor length may be allowed only within a range supported by the selected frame size. A pressure vessel diameter may limit wall thickness, material grade or allowable pressure.

    Range rules are important because many engineered products cannot be represented accurately using only yes-or-no options. The model may need formulas such as:

    Maximum flow = function of impeller diameter, speed and pressure requirement

    The exact implementation varies by CPQ platform. Some systems support formulas, constraints or external calculation services; others require custom logic or integration with engineering applications.

    Default, recommended and suggested dependencies

    A default sets an initial value but may allow the user to change it. A recommendation guides the user without necessarily preventing a choice. These rules are different from hard constraints.

    For example, a stainless steel fastener set may be recommended for an outdoor machine, while a particular fastener may be mandatory for a marine application. A recommendation supports guided selling; a mandatory rule protects product validity.

    Conditional visibility dependencies

    Visibility rules show or hide options based on earlier decisions. Selecting a diesel engine may expose fuel-system options, while selecting an electric drive exposes voltage and battery options. Visibility improves usability, but hiding an option is not the same as validating a configuration. The underlying model still needs explicit rules for compatibility and completeness.

    Automatic inclusion and substitution dependencies

    A selection may automatically add a component or substitute one component for another. Selecting a high-temperature package could add insulation, a different seal and a temperature sensor to the configurable BOM. Selecting a premium controller could replace a standard controller and change the wiring harness.

    These rules must be connected carefully to item masters, revision control and BOM logic. Otherwise, the customer-facing selection may appear correct while the downstream manufacturing structure remains incomplete.

    How dependencies fit into a product model

    A product model represents the configurable structure of a product. It usually contains attributes, option groups, allowed values, rules, calculations, components, documents and outputs. Dependencies are one layer of this model rather than the entire model.

    Product-model element Purpose Manufacturing example
    Feature or attribute Describes a product characteristic Flow rate, voltage, frame size or material
    Option Represents a selectable value or component choice Duplex impeller or 480-volt motor
    Dependency Controls relationships between choices High pressure requires reinforced casing
    Calculation Derives a value from selections Required motor power from flow and head
    Component mapping Links configuration choices to items Selected seal maps to a specific item number
    Output rule Controls documents or downstream data Generate a drawing variant or manufacturing note

    A useful model separates product knowledge into layers. Commercial rules control what can be sold or under which conditions. Engineering rules control technical feasibility. Manufacturing rules control how the product is built. Pricing rules calculate cost, margin and customer price. Integration mappings transfer the result to systems such as ERP, product lifecycle management (PLM), product data management (PDM), CAD or manufacturing execution systems (MES).

    Keeping these concerns distinguishable makes testing and ownership easier. A rule that says a premium coating adds cost is not the same as a rule that says a premium coating requires a compatible substrate.

    Rules-based, constraint-based and guided configuration

    Rules-based configuration

    Rules-based configuration uses explicit statements such as if-then conditions, requires rules, exclusions and decision tables. It is often effective for discrete product families with well-defined combinations.

    Example: if enclosure rating is IP66, then the standard ventilation option is unavailable and a sealed cooling option is required.

    Constraint-based configuration

    Constraint-based configuration describes permitted relationships and lets a solver determine whether a combination is valid. It is useful when many variables interact, especially dimensions, capacities, performance limits and mutually dependent engineering values.

    Example: the selected pump must satisfy the requested flow and pressure while remaining within limits for speed, impeller diameter, motor power and material.

    Guided selling

    Guided selling asks questions and recommends suitable choices based on customer needs. It may use dependencies, but it is not a substitute for a technical rules engine. A guided question such as “Is the machine used outdoors?” may recommend a weatherproof enclosure. The product model still needs to validate whether that enclosure is compatible with the selected voltage, cooling method and certification.

    Manufacturers should identify which rules are advisory, which are blocking and which require engineering review.

    Dependencies across engineering, BOM and pricing

    Option dependencies often have consequences beyond the configuration screen.

    Engineering calculations and CAD

    Selections may provide inputs to engineering calculations. A selected span, load, pressure, flow rate or operating temperature can determine dimensions, component ratings or material requirements. If the CPQ system connects to CAD automation, the same selections may drive a parametric model, drawing, specification sheet or 3D representation.

    However, a CPQ platform should not be assumed to provide CAD automation or engineering calculations. Buyers need to verify whether these capabilities are native, delivered through an integration or handled by a separate engineering application. The CAD and engineering automation guide explains these architectural choices.

    Configurable BOM, EBOM and MBOM

    A configurable BOM is a rule-driven structure that resolves into a product-specific list of components. An engineering bill of materials (EBOM) describes the product from an engineering perspective. A manufacturing bill of materials (MBOM) describes how the product is assembled or produced, including manufacturing-specific groupings, operations or consumables.

    A dependency can affect all three. Selecting a different motor may change the EBOM component, the MBOM assembly sequence and the purchased-item cost. The CPQ output may be a sales or engineering structure that ERP later transforms into a manufacturing structure. It is important to define which system owns each BOM and how revisions are synchronized.

    Costing and pricing

    A dependency may add or remove cost, change labor content, alter a supplier item or trigger an approval threshold. For example, a stainless steel option may change material cost, machining time and lead time. A hazardous-location package may require certified components and additional inspection.

    Pricing logic should not be confused with technical validity. A zero-price option may still be required for engineering reasons, and a priced option may be technically interchangeable with another option. Separating configuration rules from pricing rules helps prevent commercial changes from silently changing product validity.

    Related outputs such as BOMs, costing and quote documents are covered in the BOM, pricing and quoting guide.

    Manufacturing example: configurable air-handling unit

    Consider an air-handling unit configured for a commercial building. The user selects airflow, external static pressure, installation environment, heating method, cooling method, filtration level, casing material and controls.

    Several dependencies interact:

    • A higher airflow range requires a larger fan section and may exceed the selected casing width.
    • A coastal installation may require corrosion-resistant casing and fasteners.
    • A high-efficiency filter increases pressure drop and may require a larger fan motor.
    • Electric heating requires an electrical supply and control panel with sufficient capacity.
    • A heat recovery wheel may require a minimum unit width and maintenance clearance.
    • A selected building-management-system protocol may require a compatible controller and communication module.

    The product model should validate the configuration, calculate or retrieve the required fan duty, resolve components, calculate cost and produce a quote. Depending on the system architecture, it may also generate a selection report, CAD layout or manufacturing BOM. If the requested airflow and pressure fall outside the standard product envelope, the configuration can be routed to an engineer-to-order (ETO) process rather than rejected without explanation.

    Dependencies in CTO, ETO, MTO and ATO workflows

    Configure-to-order (CTO) uses predefined options and rules to produce a product from an established family. Dependencies are usually designed to prevent invalid combinations while allowing controlled variation.

    Engineer-to-order (ETO) involves engineering work for requirements that are not fully covered by the standard model. Dependencies can identify when a configuration leaves the standard envelope, collect the engineering inputs and create a structured handoff.

    Make-to-order (MTO) means production starts after an order is received, while assemble-to-order (ATO) generally uses stocked modules assembled after the order. In ATO, dependencies may determine which modules can be combined. In MTO, they may control material, routing and production-specific requirements.

    These workflows should not be treated as interchangeable. A rule that is sufficient for CTO may be inadequate for ETO, where the system must also manage engineering tasks, assumptions, approvals and revised outputs. See the manufacturing workflows guide for more detail.

    Designing maintainable option dependencies

    Use a controlled vocabulary

    Define consistent names for features, options, values, components and rule types. Avoid creating separate rules for synonyms such as high temperature, high-temp and elevated-temperature unless they represent genuinely different technical conditions.

    Separate product families and validity periods

    A rule for one pump family may not apply to another. Product revisions, supplier changes and regulatory updates can also change dependencies. The model should support effective dates, revisions or another controlled method for identifying which rules apply.

    Prefer reusable constraints over duplicated exceptions

    If five product families share the same motor-voltage relationship, represent the common logic once where the platform permits it. Duplicated rules are likely to diverge when a component or standard changes.

    Make rule ownership explicit

    Engineering may own pressure and material constraints. Product management may own commercial packaging. Manufacturing engineering may own routing or assembly rules. IT or a CPQ administrator may implement the logic, but implementation ownership should not be confused with product knowledge ownership.

    Explain why a configuration is invalid

    A message such as “invalid selection” is less useful than “The selected 100 kW motor cannot be used with the 200 mm pump because the required shaft and coupling assembly are not supported.” Clear explanations help sales engineers resolve issues and expose gaps in the product model.

    Manage exceptions deliberately

    Some customers require deviations from standard rules. An exception process should identify who approves the deviation, what engineering evidence is required, how the quote is marked and whether the exception becomes a new standard option. Allowing users to bypass rules without traceability undermines the purpose of configuration validation.

    Testing option dependencies

    Testing should cover individual rules, interactions and downstream outputs. A rule may work alone but fail when combined with dimensions, revisions, pricing or BOM mappings.

    Test area Example test
    Positive configuration A valid pump, motor, seal and voltage combination is accepted
    Negative configuration An incompatible motor and enclosure combination is blocked
    Boundary values Maximum flow and pressure limits are handled correctly
    Rule interaction High temperature plus hazardous location produces the correct requirements
    Revision behavior A discontinued component is unavailable after its effective date
    BOM resolution Required components and substitutions appear in the correct structure
    Pricing Material, labor and surcharge effects are calculated correctly
    Integration ERP, PLM or CAD receives the correct identifiers and attributes
    User explanation Blocked choices provide an actionable reason

    Manufacturers should maintain a test set of representative products, edge cases and historical configurations. Automated regression testing is particularly valuable when a shared rule affects multiple product families.

    Common limitations and failure modes

    • Rule sprawl: Hundreds of local exceptions make the model hard to review and slow to change.
    • Conflicting ownership: Sales, engineering and manufacturing may encode different interpretations of the same product rule.
    • Hidden dependencies: A rule exists in a spreadsheet, CAD macro or employee knowledge but not in the central product model.
    • Overly broad options: A single option represents several technical variants, making downstream mapping ambiguous.
    • Weak error messages: Users cannot determine how to correct an invalid configuration.
    • Uncontrolled overrides: Users bypass rules to close orders, transferring risk to engineering and production.
    • Disconnected outputs: The configuration is valid in CPQ but produces an incomplete BOM or incorrect CAD output.
    • Unmanaged changes: Component revisions or supplier substitutions are not reflected in the dependency model.

    CPQ is not a replacement for product governance. If source data, item identifiers, revisions and engineering decisions are inconsistent, a rules engine will reproduce those inconsistencies more quickly.

    Implementation approach

    1. Map the product family: Document features, options, dimensions, components, calculations, outputs and known invalid combinations.
    2. Classify the rules: Separate technical constraints, commercial rules, manufacturing rules, pricing logic and recommendations.
    3. Identify authoritative systems: Decide whether item, revision, engineering or manufacturing data comes from ERP, PLM, PDM, CAD or another source.
    4. Model the standard envelope: Define what can be configured without engineering intervention and what triggers ETO review.
    5. Build a small representative model: Test the model with real configurations, including difficult combinations and boundary values.
    6. Map outputs: Verify configurable BOMs, EBOM or MBOM structures, pricing, documents, CAD parameters and integration payloads.
    7. Establish governance: Define change requests, approvals, release procedures, ownership and audit history.
    8. Measure maintenance: Track rule defects, engineering corrections, quote rework, invalid configurations and time required to release product changes.

    The implementation architecture may include CPQ, customer relationship management (CRM), ERP, PLM, PDM, CAD, product information management (PIM) and MES. These systems have different responsibilities. CRM manages customer and opportunity context; ERP manages transactions and enterprise resources; PLM manages product lifecycle information; PDM manages design files and metadata; CAD creates design geometry; PIM manages product information for distribution; and MES supports execution on the factory floor. A CPQ implementation should define the data flow rather than assume that one system owns everything.

    The CPQ integrations guide and CPQ implementation guide provide related guidance on architecture, migration, testing and governance.

    Semantic map

    The following relationships summarize the main entities discussed in this guide:

    • CPQ configurator → applies → product configuration rules
    • Option dependencies → control → compatible product choices
    • Configuration rules → prevent → invalid combinations
    • Constraint-based configuration → validates → engineering limits
    • Guided selling → recommends → suitable product options
    • Configured product → resolves into → product-specific BOM
    • Configured product → supplies inputs to → engineering calculations
    • CAD automation → generates → product-specific drawings
    • Configuration choices → influence → cost and price
    • EBOM → represents → engineering product structure
    • MBOM → represents → manufacturing product structure
    • CPQ → exchanges data with → ERP
    • CPQ → can integrate with → PLM and PDM
    • ETO trigger → routes → non-standard configuration to engineering
    • Product governance → maintains → rules and revisions

    Frequently asked questions

    1. What is an option dependency in CPQ?

    An option dependency is a rule that defines how one product choice affects another choice, value, component, calculation or output. It may require, exclude, recommend or automatically add an option.

    2. What is a manufacturing example of an option dependency?

    Selecting a high-temperature seal on a pump may require a compatible shaft material, exclude a standard elastomer and add a temperature-rated component to the BOM.

    3. Are option dependencies the same as configuration rules?

    Option dependencies are one type of configuration rule. Configuration rules also include calculations, defaults, range limits, document triggers, BOM mappings and workflow conditions.

    4. What is the difference between a requires rule and an excludes rule?

    A requires rule makes another option or value necessary. An excludes rule prevents two options or values from being used together.

    5. Can dependencies apply to dimensions and numeric values?

    Yes. Rules can limit ranges or define relationships between dimensions, capacities, pressure, speed, load, voltage and other engineering variables.

    6. Do option dependencies generate a BOM?

    They can contribute to BOM generation by adding, removing or substituting components, but not every CPQ platform generates BOMs. The capability and resulting BOM type must be verified for the selected system.

    7. How do dependencies affect pricing?

    A dependency may add material, labor, supplier or certification costs. Technical validity and pricing should remain distinct even when both are driven by the same selection.

    8. Can dependencies drive CAD automation?

    They can provide parameters or selections to CAD automation when the CPQ architecture supports that integration. CPQ should not be assumed to include CAD generation natively.

    9. What happens when a configuration is outside the standard rules?

    The system can block it, request additional information, allow a controlled override or route it to an engineer-to-order workflow. The appropriate behavior depends on product risk and company policy.

    10. How are option dependencies tested?

    Test valid and invalid combinations, boundary values, rule interactions, revisions, BOM resolution, pricing, integrations and user-facing explanations.

    11. Who should own option dependencies?

    Product and engineering teams should own the underlying product knowledge. CPQ administrators or developers may implement it, while manufacturing and commercial teams should own relevant downstream and pricing rules.

    12. How can manufacturers prevent rule sprawl?

    Use controlled vocabularies, reusable constraints, clear product-family boundaries, explicit ownership, version control and periodic reviews of duplicate or obsolete rules.

    13. Are recommendations the same as hard constraints?

    No. A recommendation guides the user but may be overridden. A hard constraint prevents a technically or commercially invalid combination.

    14. How do option dependencies affect an EBOM and MBOM?

    A selected option may change the engineering structure, the manufacturing structure or both. The implementation should define which system creates and owns each structure.

    15. Can dependencies support configure-to-order products?

    Yes. CTO products commonly use dependencies to validate predefined options and resolve a standard product variant.

    16. Can dependencies support engineer-to-order products?

    Yes, but they normally need to identify the boundary of standard configuration and trigger engineering review rather than pretending every design can be fully automated.

    17. Why are clear validation messages important?

    They tell sales engineers what must change and expose the reasoning behind a rule. This reduces trial and error and helps users trust the configurator.

    18. What enterprise systems are commonly related to option dependencies?

    Depending on the architecture, dependencies may exchange data with CRM, ERP, PLM, PDM, CAD, PIM or MES. These systems are complementary and should not be treated as interchangeable.

    19. Should all product knowledge be stored in CPQ?

    No. CPQ should use authoritative product and engineering data from the appropriate systems while managing the configuration logic required for a valid quote and downstream handoff.

    20. What is the first step in implementing option dependencies?

    Start by documenting a representative product family, its options, engineering limits, invalid combinations, component mappings, pricing effects and non-standard cases before selecting or building rules.