Cardinality rules in CPQ product models define how many instances of an option, component, feature or subassembly a user may select. A rule can specify a minimum, maximum or exact quantity, such as requiring one motor, allowing up to four lifting points or permitting exactly two battery modules.
In manufacturing Configure, Price, Quote (CPQ), cardinality is more than a user-interface setting. It is part of the product model that controls configuration validity, component quantities, pricing, Bill of Materials (BOM) generation and sometimes engineering or Computer-Aided Design (CAD) outputs. A well-designed rule prevents a sales user from quoting a machine that cannot be built, while a poorly designed rule can create false restrictions, incomplete BOMs or excessive manual review.
This guide explains how cardinality works, how it differs from other configuration rules, where it fits in the CPQ architecture and how manufacturers can implement and maintain it.
What is a cardinality rule?
A cardinality rule limits the number of selections or instances associated with a configurable product relationship. It is usually expressed as a minimum and maximum value:
- Minimum cardinality: the smallest permitted number of selections.
- Maximum cardinality: the largest permitted number of selections.
- Exact cardinality: the minimum and maximum are the same.
- Unbounded or open cardinality: the model permits a variable number of instances, subject to other constraints.
For example, a pump package may require one drive motor, allow one or two standby pumps and allow up to six monitoring sensors. The cardinality rules describe the permitted count for each relationship without necessarily deciding which specific option is selected.
| Rule | Example | Manufacturing effect |
|---|---|---|
| Exactly one | 1 motor for each pump skid | Prevents an incomplete or over-motorized assembly |
| Zero or one | Optional heater | Allows the feature to be omitted or selected once |
| One or more | At least one safety valve | Ensures a required functional capability |
| Zero to four | Additional lifting lugs | Supports variable quantities in a configurable BOM |
| Exactly two | Two battery modules in a vehicle pack | Ensures a balanced or required system design |
How cardinality fits into a CPQ product model
A CPQ product model represents the structure and logic of a configurable product. It may contain products, assemblies, features, options, attributes, constraints, calculations, prices and output mappings. Cardinality typically applies to the relationship between a parent item and a child option or component.
For example, a material-handling machine model might contain:
- one base vehicle;
- one powertrain selected from diesel, electric or hybrid options;
- zero or one enclosed operator cabin;
- zero to three auxiliary hydraulic circuits;
- one to four stabilizer legs;
- zero or one remote-control package.
The cardinality rule tells the CPQ system how many child selections are allowed. Other rules determine whether those selections are compatible. For example, an electric powertrain may require a minimum battery capacity, while a remote-control package may require a specific control system. Cardinality alone does not express every engineering relationship.
Manufacturers should document the product model separately from the user interface. A visual configurator may show four empty attachment positions, but the underlying model still needs explicit rules defining whether zero, one, two, three or four attachments are valid and how each selection affects the BOM, price and engineering outputs.
See the guide to product configuration for the wider relationship between product options, dependencies, constraints and validation.
Common cardinality patterns in manufacturing
Required single selection
A required single selection has a cardinality of one to one. It is appropriate when every finished product must contain exactly one component or option. Examples include one motor on a pump, one control cabinet on a machine or one chassis on a specialty vehicle.
This rule does not necessarily mean that there is only one available product. A user may choose one motor from several valid motor options. The cardinality controls quantity; a separate selection rule controls the available alternatives.
Optional single selection
A zero-to-one relationship allows a feature to be omitted or selected once. Examples include an insulation package on an industrial tank, a cab air-conditioning unit on construction equipment or a protective coating on a fabricated assembly.
Optional does not mean unrestricted. The option may still be required when another feature is selected. For example, a cold-weather package may require the insulation package even though insulation is generally optional.
Multiple selections with a fixed maximum
A zero-to-four or one-to-six relationship supports repeated components. This is common for sensors, lifting points, auxiliary outlets, shelves, nozzles, lighting units and attachment positions.
The maximum should reflect a physical, safety or process limit. If a machine can accept four sensors but the electrical cabinet supports only three input channels, the cardinality should not be four unless the model also includes a rule that adds the required expansion hardware.
Exact repeated quantity
An exact quantity is useful when the design requires a fixed number of identical or related components. Examples include two drive motors on a tandem conveyor, four wheels on a vehicle or two redundant pressure sensors in a safety system.
Exact cardinality can also support manufacturing standards. A product family may require two lifting eyes for a defined load class even though the commercial configurator presents the requirement as a single package selection.
Variable quantity based on an input
Some models derive quantity from an engineering input rather than allowing direct selection. A cable tray may require a number of supports based on length. A heat exchanger may require a number of tube bundles based on capacity. A modular conveyor may require additional frame sections based on overall length.
This is often implemented with a calculation, formula or quantity rule. The resulting quantity behaves like cardinality in the BOM, but it should be distinguished from a user selecting repeated options manually. The model must define rounding, minimums, maximums and exceptions.
Cardinality rules versus other configuration rules
Cardinality answers the question, “How many may be selected?” It does not by itself answer whether a selection is compatible, what value an attribute may have or what component should be generated.
| Rule type | Main question | Example |
|---|---|---|
| Cardinality | How many? | Up to four hydraulic outlets |
| Compatibility constraint | Can these selections coexist? | High-temperature seals require a compatible fluid package |
| Attribute validation | Is the entered value within range? | Tank diameter must be between 800 and 2,400 millimetres |
| Dependency rule | What must or must not accompany this option? | A second pump requires a larger control panel |
| Selection rule | Which alternatives are available? | Only approved motors are shown for a voltage class |
| Quantity calculation | What quantity should be generated? | One support bracket per 1.5 metres of rail |
Rules-based configuration uses explicit conditions such as “if option A is selected, require option B.” Constraint-based configuration evaluates permitted combinations and values, often across many variables. Guided selling simplifies the user experience by asking business questions and recommending a configuration. A manufacturing CPQ implementation may use all three approaches, but guided selling does not replace the underlying cardinality and engineering rules.
Manufacturing examples
Pump skid
A pump skid may include one duty pump, zero or one standby pump, one motor per pump and zero to eight instrumentation points. If a standby pump is selected, the model may require a second motor, additional isolation valves and a larger base frame. The cardinality rules control the number of pumps and instruments; dependency and compatibility rules control the associated equipment.
The configured result may produce a configurable BOM with quantities for pumps, motors, valves, transmitters, cable glands and structural members. A pricing engine can use the same quantities to calculate material and labour costs, while an engineering system may use the selections to generate a layout or datasheet.
Industrial enclosure
An electrical enclosure may allow zero to twelve cable entries, one or two cooling fans and zero or one heater. The number and location of cable entries affect gland plates, internal clearance and machining operations. Selecting two fans may require a larger power supply and a different control circuit.
A simple cardinality rule cannot validate physical placement or heat dissipation. Those requirements need spatial, electrical or thermal constraints, calculations or engineering review.
Specialty vehicle
A configurable utility vehicle may allow two to six seats, zero or one winch, zero to four auxiliary work lights and one or two battery modules. A second battery may be permitted only with a high-capacity charger and a revised battery enclosure. The configuration can therefore contain both quantity limits and conditional dependencies.
Cardinality and BOM generation
A Bill of Materials (BOM) lists the components, subassemblies and quantities needed for a product. Cardinality affects the BOM when each selected instance maps to one or more BOM items.
Manufacturers should distinguish:
- Configurable BOM: a model containing alternatives, optional items, rules or quantity logic before a specific order is configured.
- Engineering BOM (EBOM): the product structure used by engineering to describe the designed product.
- Manufacturing BOM (MBOM): the production-oriented structure used for manufacturing, assembly, operations and sometimes plant-specific requirements.
One selected auxiliary circuit may generate a valve, hose kit, control output and mounting hardware. If the user selects three circuits, the CPQ system must either repeat those items three times or apply a quantity formula. That mapping needs to be explicit. A cardinality rule that changes the user interface but does not change downstream quantities is incomplete.
Read more about BOM generation, costing, pricing and quote automation.
Cardinality, pricing and quoting
Cardinality and pricing are related but separate concerns. The cardinality rule determines whether a quantity is valid. Pricing logic determines the commercial effect of that quantity.
For example, the first two sensors on a machine may have standard pricing, while sensors three and four may receive a volume discount or require a higher-capacity signal module. The quote may also include one-time engineering charges if the quantity exceeds a standard package.
Costing may include material, purchased components, assembly labour, testing and engineering effort. A CPQ system should not assume that multiplying a unit price by quantity produces an accurate manufacturing price. Some costs are fixed, tiered or triggered only when a threshold is crossed.
Cardinality in CTO, MTO and ETO workflows
Configure-to-order (CTO) uses predefined options and combinations. Cardinality rules are usually highly structured because the product is designed for repeatable configuration.
Make-to-order (MTO) produces a product after an order is received, often from a controlled set of specifications. Cardinality may govern selected components while manufacturing planning determines the final production structure.
Engineer-to-order (ETO) requires new or adapted engineering for a customer order. Cardinality rules can screen standard options and identify when a request exceeds the standard model, but they do not eliminate engineering work. For example, a CPQ model might permit up to four nozzles in a standard vessel but route a request for five nozzles to engineering review.
Assemble-to-order (ATO) combines stocked modules or subassemblies. Cardinality often controls the number of modules, but inventory and plant constraints may also need to be checked.
These distinctions are important because a rule that is sufficient for CTO may be only a front-end guardrail for ETO. See the manufacturing workflow guide for the relationship between configuration, engineering and production.
System architecture and data flow
In a manufacturing CPQ architecture, cardinality data may be authored in the CPQ product model or synchronized from another product-lifecycle system. The appropriate ownership depends on the implementation.
- A product manager or engineer defines the product structure and valid quantities.
- The CPQ model exposes selectable options and quantity controls to the sales or dealer user.
- The rules engine validates the configuration in real time and again at submission.
- Pricing and costing logic evaluates the selected quantities.
- The CPQ system generates a quote, configuration record and, where supported, a BOM or order structure.
- ERP, Product Lifecycle Management (PLM), Product Data Management (PDM), Manufacturing Execution System (MES) or CAD systems receive the relevant output.
Enterprise systems are not interchangeable. Customer Relationship Management (CRM) may hold the opportunity and account. Enterprise Resource Planning (ERP) may manage items, inventory, orders and manufacturing transactions. PLM or PDM may govern engineering structures and revisions. CAD may generate geometry and drawings. Product Information Management (PIM) may manage commercial product content. MES may coordinate shop-floor execution.
Integration decisions should define which system owns option identifiers, revision status, valid dates, quantities, BOM mappings and approval status. More detail is available in the CPQ integration guide.
Implementation guidance
Model the relationship, not just the screen
Do not implement cardinality only as a maximum number of clicks or rows in the interface. Define the parent, child, quantity meaning, physical limit, applicable product revisions and downstream output.
Use explicit units and identifiers
Quantities should have clear units and stable identifiers. “Three outlets” may mean three commercial options, three physical ports or three complete outlet assemblies. Those meanings should not be left to interpretation.
Separate standard limits from engineering limits
A standard product may allow zero to four attachments, while an engineer could approve five for a special project. Decide whether five is forbidden, allowed through an ETO route or represented as a separate product variant. Do not silently override a standard rule.
Test boundaries
Test zero, minimum, maximum and maximum-plus-one values. Also test combinations around dependencies: one pump, two pumps, maximum sensors with one pump, maximum sensors with two pumps and invalid combinations involving incompatible materials or power ratings.
Version rules with the product
Cardinality may change when a component is redesigned, a safety standard changes or a manufacturing plant introduces a new limitation. Rules need effective dates, ownership, approval and revision control. A quote created under one product revision should remain reproducible even after the model changes.
Make rules explainable
When a user cannot select a third battery module, the message should explain why: for example, “This chassis supports a maximum of two modules” or “A third module requires the reinforced frame package.” Explainable validation reduces sales-engineering queries and helps administrators maintain the model.
Limitations and common failure modes
- Confusing option count with physical quantity: one selected package may contain several physical components.
- Ignoring downstream mappings: the interface allows multiple selections but the BOM or ERP order contains only one item.
- Using cardinality for every rule: quantity limits cannot replace electrical, structural, thermal or regulatory calculations.
- Hard-coding limits: values embedded in custom code are harder to audit and revise than governed model data.
- Overly broad maximums: permissive models create configurations that require manual engineering review.
- Missing revision context: a quantity valid for one product generation may be invalid for another.
- Weak error handling: users receive a generic validation failure instead of a useful engineering explanation.
Not every CPQ platform supports the same depth of cardinality, constraint, BOM, CAD or engineering logic. During software evaluation, verify whether the system supports minimum and maximum quantities, repeated components, conditional quantities, revision control, calculated quantities, validation messages and downstream mappings. Confirm these capabilities with a representative product model rather than relying on a generic feature list.
How to evaluate cardinality support in CPQ software
| Evaluation area | Questions to verify |
|---|---|
| Model structure | Can a parent contain repeated child components and nested assemblies? |
| Rule logic | Can minimum, maximum and exact quantities be combined with dependencies? |
| Quantity calculation | Can quantities be derived from dimensions, capacity or length? |
| Validation | Are boundary conditions and cross-component constraints supported? |
| BOM output | Do repeated selections create correct quantities in configurable, engineering or manufacturing structures? |
| Pricing | Can quantity tiers, fixed charges and threshold costs be represented separately? |
| Integration | Can rule and product revisions be exchanged with ERP, PLM, PDM, CAD or CRM? |
| Governance | Can product owners test, approve, version and audit changes? |
| Workflow | Can invalid or nonstandard quantities be routed to engineering approval? |
A practical proof of concept should use a real configurable assembly, such as a pump skid, electrical enclosure or vehicle body. Include optional items, repeated components, calculated quantities, a pricing threshold and a BOM output. This reveals limitations that a simple option-selection demonstration may hide.
Semantic map
The following relationships summarize how cardinality connects product configuration with engineering and manufacturing systems:
- CPQ product model → contains → configurable products, assemblies and options
- Cardinality rule → limits → the quantity of selectable components
- Minimum cardinality → enforces → required product elements
- Maximum cardinality → prevents → excessive or unsupported component quantities
- Compatibility constraint → validates → relationships between selected options
- Configured product → generates → a configuration record and possible BOM
- Repeated component selection → changes → BOM quantity and manufacturing requirements
- Quantity calculation → derives → component count from dimensions or capacity
- Pricing engine → evaluates → quantity-based cost and price rules
- CPQ → exchanges data with → ERP, CRM, PLM, PDM, CAD or MES
- CAD automation → generates → product-specific geometry or drawings when supported
- ETO workflow → routes → nonstandard configurations to engineering review
Frequently asked questions
1. What is cardinality in CPQ?
Cardinality is the permitted number of selections or instances in a CPQ product model, expressed through minimum, maximum or exact quantities.
2. What is an example of a cardinality rule?
A machine may allow zero to four auxiliary hydraulic circuits. Zero means the feature is optional, while four is the maximum supported quantity.
3. Is cardinality the same as an option dependency?
No. Cardinality controls how many items may be selected. A dependency controls what must, may or may not accompany a selection.
4. What does a cardinality of one-to-one mean?
It means exactly one instance is required. A pump skid might require exactly one base frame or one control cabinet.
5. What does zero-to-one cardinality mean?
It means an option can be omitted or selected once. It is commonly used for optional heaters, coatings, cabins and accessories.
6. Can cardinality rules control repeated components?
Yes. They can allow repeated sensors, valves, lights, seats, outlets or modular sections, provided the CPQ model maps those selections correctly to downstream data.
7. Can cardinality be calculated from a dimension?
Yes, in systems that support calculated quantities. For example, a model may derive the number of conveyor supports from conveyor length and a defined spacing rule.
8. How do cardinality rules affect a BOM?
They can change the quantity of BOM items or the presence of repeated subassemblies. The model must explicitly map selected instances to configurable, engineering or manufacturing BOM output.
9. Do cardinality rules determine price?
No. They determine whether a quantity is valid. Pricing logic separately calculates unit prices, quantity breaks, fixed charges, discounts and additional engineering or manufacturing costs.
10. Can cardinality rules replace engineering calculations?
No. They can enforce basic quantity limits, but structural, thermal, electrical, hydraulic and regulatory requirements may need calculations or specialized validation.
11. How are cardinality rules used in configure-to-order?
In Configure-to-order, cardinality helps keep selections within a predefined, repeatable product design and supports reliable BOM and order output.
12. How are cardinality rules used in engineer-to-order?
They define the standard product boundary. A request outside that boundary can be blocked or routed to engineering for review rather than treated as a normal configuration.
13. Should cardinality rules live in CPQ or PLM?
Ownership depends on the architecture. CPQ may own commercial configuration logic, while PLM or PDM may govern engineering structures. Ownership, synchronization and revision rules must be explicit.
14. What is the difference between a configurable BOM and a cardinality rule?
A configurable BOM describes alternatives, options and quantities for a product family. Cardinality is one type of rule that controls how many related items may be selected within that structure.
15. How should manufacturers test cardinality?
Test zero, minimum, maximum and maximum-plus-one values, then test combinations with dependencies, dimensions, pricing thresholds and BOM output.
16. What happens if a user exceeds the maximum?
A well-designed CPQ system blocks the invalid configuration or provides a clear route to an engineering approval process. It should explain the physical or product-model reason.
17. Can cardinality vary by product revision?
Yes. A new chassis, control panel or safety design may change permitted quantities. Rules should be versioned with effective dates and product revisions.
18. What should a CPQ software evaluation demonstrate?
The demonstration should include nested assemblies, repeated components, calculated quantities, conditional dependencies, pricing effects, revision control and accurate BOM or order output for a real manufactured product.
For implementation planning, rule governance, testing and maintenance, consult the CPQ implementation guide. For CAD and engineering dependencies, see the CAD and engineering automation guide.