Solution configuration configures a complete system made from multiple products, assemblies or services, while single-product configuration configures one product model or product family at a time. In manufacturing CPQ, the difference is not simply the number of items in a quote. It determines where rules are stored, how compatibility is validated, how prices and costs are calculated, and whether the output is one product record or a coordinated solution with multiple bills of material (BOMs).
For example, configuring one centrifugal pump with a selected motor, seal and material options is single-product configuration. Configuring a complete pumping skid with several pumps, a base frame, valves, sensors, control panels, piping and installation requirements is solution configuration. The skid may contain several independently configurable products, but the system must also validate relationships between them.
A manufacturing CPQ system may support one or both approaches. Buyers should verify the actual capabilities of each platform rather than assume that a product configurator automatically supports multi-product system design, engineering calculations, configurable BOMs or computer-aided design (CAD) automation.
What is single-product configuration?
Single-product configuration is the process of selecting valid options and parameters for one configurable product, product family or engineered assembly. The configuration model normally contains the product structure, available options, dependencies, constraints, calculations and outputs for that product.
In manufacturing, a single product can still be technically complex. A configurable industrial pump may require decisions about flow rate, head, impeller diameter, casing material, motor power, voltage, seal type, connection size and environmental conditions. The configurator must determine whether those selections are compatible and may calculate a product-specific price, cost, BOM or drawing.
Typical single-product model
- Features and options: such as motor voltage, frame material or connection type.
- Dependencies: for example, a high-temperature seal is available only with certain casing materials.
- Constraints: such as a motor size that cannot be used with a particular pump frame.
- Calculations: such as power requirements, capacity, weight or dimensional values.
- Outputs: such as a configured item number, price, product-specific BOM or CAD parameters.
This model is often appropriate for standard or configurable-to-order products where the main engineering problem is selecting options within one product family. It can support configure-to-order (CTO), make-to-order (MTO) or, in some cases, engineer-to-order (ETO) workflows depending on how much design work remains after configuration.
What is solution configuration?
Solution configuration is the process of selecting and coordinating multiple products, subsystems, assemblies and services so that the complete combination satisfies technical, commercial and operational requirements.
A solution may include products from different product families. A material-handling system, for example, may contain conveyors, transfer stations, motors, drives, guarding, sensors, control cabinets and software. Each item may have its own configuration rules, but the solution also requires cross-product rules.
Examples of cross-product rules include:
- a selected conveyor width must match the transfer station opening;
- the motor and variable-frequency drive must support the required load and voltage;
- the control panel must have enough inputs and outputs for the selected sensors;
- the pump, valve and pipe materials must be compatible with the process fluid;
- the selected vehicle body must fit the chassis wheelbase and payload rating;
- the total electrical load must remain within the selected power-supply capacity;
- the system must meet site, safety, environmental or regulatory requirements.
Solution configuration therefore combines product configuration with system architecture, compatibility management and sometimes engineering design. It is especially relevant to industrial machinery, HVAC systems, electrical equipment, automation cells, specialty vehicles, energy systems and engineered skids.
Key differences between the two approaches
| Criterion | Single-product configuration | Solution configuration |
|---|---|---|
| Scope | One product model or family | Multiple products, assemblies, systems or services |
| Rules | Rules mainly govern options within one product | Rules govern both local options and relationships between products |
| Example | Configuring a pump | Configuring a complete pumping station |
| Primary output | Configured product, item number, price and possibly BOM | Coordinated solution structure, multiple outputs and system-level price |
| Engineering | Product-specific calculations or parameter selection | System sizing, interface validation, layout and integration engineering |
| BOM | Usually one configurable BOM or product assembly | Several product BOMs plus a solution-level structure |
| Quoting | One product line or related option lines | Multi-line commercial offer with packages, services and exclusions |
| Risk | Invalid option combinations | Invalid interfaces, incomplete scope or incompatible subsystems |
How product models differ
A single-product model usually starts with a product family and its option structure. The model may represent a base pump, valve, enclosure, vehicle or machine. Rules are attached to features, options, attributes and variant parts.
A solution model adds a higher-level structure. It may contain:
- a solution template, such as a water-treatment skid or packaging line;
- required and optional subsystems;
- one or more product models for each subsystem;
- interface definitions between subsystems;
- system-level calculations and capacity limits;
- commercial rules for packages, services, freight and installation;
- outputs that connect the solution to engineering, production and service systems.
The distinction between a product model and a solution model is important for governance. A pump product manager may own pump options and pump rules. A systems engineering team may own rules about pump-to-pipe, pump-to-motor or pump-to-control-panel compatibility. If these responsibilities are not defined, changes can create contradictory rules or duplicate logic.
Rules and constraints in single-product configuration
Single-product configuration generally relies on rules within a bounded product domain. Common rules include:
- Option compatibility: option A requires or excludes option B.
- Value ranges: a dimension or capacity must remain within defined limits.
- Conditional availability: an option appears only when a prior choice makes it relevant.
- Technical calculations: a motor or frame is selected based on load, speed or capacity.
- Variant mapping: a configuration maps to a stock keeping unit, material number or manufacturing variant.
These rules can be implemented as rules-based configuration, constraint-based configuration or a combination. Rules-based configuration commonly expresses explicit conditions such as if-then relationships. Constraint-based configuration evaluates permitted combinations against limits, relationships and requirements. Guided selling helps a user reach a suitable configuration through questions, but it is not necessarily the same as a complete engineering constraint solver.
More detail on product models, dependencies and validation is available in the guide to product configuration.
Rules and constraints in solution configuration
Solution configuration requires all of the rules used by single-product configuration plus rules that cross product boundaries. These cross-product constraints often represent engineering interfaces rather than simple option dependencies.
Common cross-product rule types
- Dimensional interfaces: a selected pipe diameter must match a valve connection or machine inlet.
- Capacity relationships: the cooling unit must handle the heat load produced by the selected equipment.
- Electrical relationships: motors, drives, transformers and panels must use compatible voltage, current and protection ratings.
- Performance relationships: a pump curve, fan capacity or conveyor speed must satisfy the system requirement.
- Spatial relationships: equipment must fit within a defined footprint or vehicle body.
- Regulatory relationships: selected components may need to meet a common certification or safety category.
- Commercial relationships: installation, commissioning or service packages may be required for a particular system.
In a mature architecture, these rules should be explicit and testable. Storing them informally in sales notes, spreadsheets or individual employee knowledge makes the solution model difficult to maintain and increases the risk of invalid quotes.
Manufacturing examples
Example 1: Industrial pump
Single-product configuration begins with the required flow and pressure. The model selects pump size, impeller, casing, seal, motor and connection standard. It may generate a configured BOM and a price.
Solution configuration begins when the customer is buying a complete pumping package. The model must coordinate several pumps, a skid frame, valves, strainers, instrumentation, a control panel and piping. It must check duty and standby arrangements, pipe interfaces, motor voltage, control-panel capacity and the physical arrangement of the skid. The quote may also include testing, documentation and installation.
Example 2: HVAC system
A single air-handling unit can be configured by selecting airflow, casing, filters, coils, fans and controls. A complete HVAC solution adds chillers, pumps, duct interfaces, controls, electrical equipment and site-specific requirements. The solution model must verify capacity and compatibility across the system, not merely validate each unit independently.
Example 3: Specialty vehicle
A single-product model may configure a truck body using body length, material, compartments, doors, lifting equipment and lighting. A solution model may combine a chassis, body, hydraulic system, power take-off, control system and customer-specific accessories. Payload, axle loads, center of gravity, electrical load and mounting interfaces become system-level constraints.
Pricing, costing and quoting implications
Configuration determines what can be sold, but it does not automatically determine how the solution should be priced. Pricing and quoting are related capabilities that may use configuration results as inputs.
For single-product configuration, pricing may be based on a base model plus option prices, dimensions, materials, labor assumptions or calculated costs. For solution configuration, pricing may require:
- prices for each configured product and assembly;
- system-level discounts or package rules;
- engineering, installation, commissioning and documentation services;
- freight, site work and project-specific commercial terms;
- currency, tax, dealer and regional pricing;
- risk allowances or approval thresholds for non-standard work.
A solution quote should make scope visible. It should distinguish included equipment from optional items, customer responsibilities, exclusions and engineering assumptions. A generic sales CPQ tool may produce a commercial quote but may not maintain the engineering structure or manufacturing data needed for a complex solution.
See the guide to BOM generation, pricing and quoting for the relationship between configuration outputs and commercial documents.
BOM and engineering outputs
A bill of material (BOM) is a structured list of components required to make or deliver a product. In manufacturing, an engineering BOM (EBOM) represents the design view, while a manufacturing BOM (MBOM) represents how the product is assembled or produced. A configurable BOM contains rules or variant logic that determines which components are included for a particular configuration.
Single-product configuration may produce one configurable product structure. Solution configuration may produce:
- a solution-level structure containing several configured products;
- an EBOM for system design;
- separate product or subsystem BOMs;
- an MBOM or production structure after manufacturing transformation;
- installation, spare-parts or service lists.
These outputs are not interchangeable. A CPQ platform may generate a quote line structure without generating an EBOM or MBOM. It may also pass selected parameters to an enterprise resource planning (ERP) system without owning the authoritative engineering structure. Integration design must define which system owns each output.
CAD, visualization and engineering calculations
Single-product configuration can pass parameters to a parametric CAD model, such as length, hole pattern, mounting position or material thickness. The CAD system may then generate a product-specific model or drawing.
Solution configuration adds layout and interface questions. A system may need to position multiple products, route pipes or cables, check clearances and produce an arrangement drawing. Some platforms support these functions through CAD or design-automation integrations; others stop at selections, pricing and document generation.
Three-dimensional visualization can help users understand a configured product or solution, but visual appearance is not proof of engineering validity. A 3D view may not validate pressure ratings, electrical load, structural strength, thermal performance or manufacturing feasibility. Engineering calculations and authoritative CAD or product lifecycle management (PLM) data may still be required.
Review the guide to CAD and engineering automation in CPQ when evaluating these requirements.
Where each approach fits in manufacturing workflows
| Workflow | Single-product fit | Solution-configuration fit |
|---|---|---|
| Configure-to-order (CTO) | Strong fit when one product has defined variants | Useful for standard systems assembled from validated modules |
| Make-to-order (MTO) | Useful when options drive production without a new design | Useful when several MTO products must be coordinated |
| Engineer-to-order (ETO) | May capture requirements before engineering | Useful as a system-level specification and engineering handoff |
| Assemble-to-order (ATO) | Useful for selecting stocked modules | Useful when modules must be combined under interface rules |
In an ETO process, solution configuration should not be presented as a substitute for engineering review. It can capture requirements, select known modules, identify non-standard conditions and create a structured handoff. The engineering team may still need to design new components, approve calculations and release final production data.
The manufacturing workflows guide explains how configuration connects sales, engineering and production.
System architecture and integrations
A typical architecture separates responsibilities across several systems:
- CPQ: manages configuration interaction, rules, pricing inputs and quote generation.
- Customer relationship management (CRM): manages accounts, opportunities and sales activities.
- ERP: manages items, orders, inventory, purchasing, production and financial transactions.
- PLM: manages product structures, revisions, requirements and lifecycle control.
- Product data management (PDM): manages engineering files and CAD-related product data.
- CAD: creates geometry, drawings and design outputs.
- Product information management (PIM): manages commercial product information and content for channels.
- Manufacturing execution system (MES): manages production execution and shop-floor information.
For single-product configuration, the main integration may be between CPQ, ERP and CAD or PLM. For solution configuration, integration must also preserve relationships between subsystems, revisions, quantities, interfaces and project-specific outputs. APIs and event-based integration may be needed when configuration changes must update pricing, engineering structures and order data without manual re-entry.
More integration considerations are covered in the CPQ integration guide.
Benefits and limitations
Benefits of single-product configuration
- More focused product models and ownership.
- Faster validation for bounded option sets.
- Simpler testing and release management.
- Clearer mapping to product numbers, prices and BOM variants.
- Good support for repeatable CTO and MTO products.
Benefits of solution configuration
- Validates the complete system instead of isolated products.
- Reduces manual coordination between sales and application engineering.
- Improves completeness of multi-product quotes and proposals.
- Creates a structured starting point for engineering and project execution.
- Supports modular systems, packages and repeatable solution architectures.
Limitations and risks
- Solution models are more difficult to design, test and govern.
- Cross-product rules can become duplicated or contradictory.
- Engineering calculations may exceed the capabilities of a commercial configurator.
- Incomplete master data can make technically valid configurations impossible to manufacture.
- Large product models can create slow user experiences and difficult change management.
- Automatic BOM or CAD output may require specialized integrations rather than standard CPQ features.
- Complex ETO work still requires engineering judgment and formal approval.
How to choose the right configuration approach
Use single-product configuration when the customer is selecting a defined product family and the important rules remain inside that family. Use solution configuration when the value proposition, technical validity or commercial scope depends on relationships between multiple products or subsystems.
Many manufacturers need a layered approach rather than an either-or decision:
- model each product family independently;
- reuse those models within solution templates;
- add cross-product interface rules at the solution level;
- apply system-level calculations and commercial rules;
- generate the appropriate quote, BOM, CAD and engineering handoff outputs.
This architecture avoids rebuilding every product rule inside every solution. It also makes ownership clearer: product teams maintain local rules, while systems or application engineering teams maintain interface rules.
Implementation and governance considerations
Start with a product and solution inventory. Identify which offerings are true single products, which are packages of existing products and which require new system engineering for every order. Document the input parameters, constraints, calculations, outputs and responsible owners for each category.
Important implementation activities include:
- defining a common vocabulary for features, options, interfaces, constraints and requirements;
- separating product rules from pricing rules and document rules;
- identifying the system of record for product structures and revisions;
- establishing ownership for local product rules and cross-product rules;
- testing valid, invalid, boundary and changed configurations;
- versioning rules alongside product and engineering revisions;
- testing ERP, PLM, PDM, CAD and CRM data exchanges;
- measuring quote completeness, configuration errors, engineering rework and maintenance effort;
- defining an approval path for non-standard or ETO configurations.
Do not begin with an attempt to model every possible solution. A controlled pilot around one product family or repeatable solution type usually exposes data, ownership and integration problems earlier. The CPQ implementation guide provides a broader framework for requirements, testing, governance and maintenance.
Semantic map
The following relationships summarize the main entities and concepts in this article:
- Single-product configuration → configures → one product family or engineered assembly
- Solution configuration → coordinates → multiple configurable products
- Configuration rules → prevent → invalid option combinations
- Cross-product constraints → validate → subsystem interfaces
- Product model → defines → features, options, parameters and outputs
- Solution model → contains → product models and system-level rules
- Configured product → can generate → product-specific BOM data
- Solution configuration → can generate → a coordinated solution structure
- CPQ → calculates or applies → configuration-dependent prices
- CPQ → exchanges data with → ERP
- CPQ → can pass parameters to → CAD automation
- CAD automation → generates → product-specific drawings or models
- EBOM → represents → the engineering product structure
- MBOM → represents → the manufacturing assembly structure
- ETO workflow → requires → engineering review for non-standard design
- Solution configuration → supports → system-level quoting and engineering handoff
Frequently asked questions
What is the main difference between solution configuration and single-product configuration?
Single-product configuration validates one product model. Solution configuration validates multiple products and the relationships between them, such as dimensional, electrical, performance and commercial interfaces.
Is a product configurator the same as a solution configurator?
No. A product configurator may handle one product family, while a solution configurator coordinates several product models and system-level constraints. Some CPQ platforms support both, but this must be verified.
Can single-product configuration support complex industrial equipment?
Yes. A single industrial machine may require extensive option rules, calculations, pricing logic and BOM generation even when it is modeled as one product.
When does a product become a solution?
It becomes a solution when the commercial or technical result depends on multiple products, subsystems, services or interfaces rather than on options within one product family.
Does solution configuration always require CAD automation?
No. CAD automation is useful when configuration must create geometry or drawings, but solution configuration can also stop at validated selections, pricing and structured engineering requirements.
Can a CPQ system generate a solution BOM?
Some manufacturing CPQ systems can generate configurable BOMs or solution structures, while others only create quote lines or pass selections to ERP and PLM. Buyers should verify the exact output and ownership model.
What is a cross-product constraint?
A cross-product constraint is a rule relating separate products or subsystems, such as requiring a selected motor, drive and control panel to use compatible voltage and load ratings.
How does solution configuration affect pricing?
It adds system-level pricing considerations such as package discounts, installation, commissioning, freight, engineering services and project-specific commercial assumptions.
Is guided selling sufficient for solution configuration?
Guided selling can help users answer requirements questions, but it does not necessarily validate engineering constraints or generate manufacturing-ready outputs.
What is the role of ERP in solution configuration?
ERP usually manages items, orders, inventory, purchasing, production and financial transactions. It may receive configured products, quantities, prices or BOM data from CPQ.
What is the role of PLM in solution configuration?
Product lifecycle management, or PLM, may manage product structures, revisions, requirements and engineering lifecycle data. It can be the authoritative source for product and engineering information.
How do EBOM and MBOM differ in a configured solution?
An engineering BOM describes the design structure, while a manufacturing BOM describes how the product is built. A solution may require both, along with a mapping between them.
Can solution configuration support engineer-to-order projects?
Yes, it can capture requirements, select reusable modules and identify non-standard conditions. However, new design work, calculations and approvals may still require engineering.
Should product and solution rules be stored together?
Usually, local product rules should remain with their product models, while cross-product interface rules should be maintained at the solution level. This reduces duplication and clarifies ownership.
How should solution configuration be tested?
Test valid combinations, invalid combinations, boundary values, interface mismatches, revision changes, pricing results, BOM outputs and integrations with ERP, PLM, CAD and related systems.
What is the best starting point for implementing solution configuration?
Start with one repeatable solution type, document its product models and interfaces, establish rule ownership, and test the complete flow from requirements through quote and engineering handoff.