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 requirementThe 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
- Map the product family: Document features, options, dimensions, components, calculations, outputs and known invalid combinations.
- Classify the rules: Separate technical constraints, commercial rules, manufacturing rules, pricing logic and recommendations.
- Identify authoritative systems: Decide whether item, revision, engineering or manufacturing data comes from ERP, PLM, PDM, CAD or another source.
- Model the standard envelope: Define what can be configured without engineering intervention and what triggers ETO review.
- Build a small representative model: Test the model with real configurations, including difficult combinations and boundary values.
- Map outputs: Verify configurable BOMs, EBOM or MBOM structures, pricing, documents, CAD parameters and integration payloads.
- Establish governance: Define change requests, approvals, release procedures, ownership and audit history.
- 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.