Technical validation during product configuration is the process of checking whether a proposed product is technically valid, manufacturable and complete before the manufacturer issues a quote or releases an order. In a manufacturing CPQ configurator, validation can check option compatibility, dimensions, materials, load requirements, electrical ratings, capacity calculations, required components and downstream production data.
This is more than confirming that a customer selected a permitted option. A manufacturing-focused Configure, Price, Quote (CPQ) system may need to determine whether a pump can deliver the requested flow at the specified head, whether a machine frame supports the selected load, whether a motor matches the power requirement, or whether the resulting bill of materials (BOM) contains every component required for production. Some platforms support these functions natively; others require integration with engineering, product lifecycle management or custom calculation services.
The purpose of technical validation is to identify invalid or incomplete configurations while the product is being configured, rather than after the quote reaches engineering or production. It reduces avoidable rework, but it does not replace engineering review for products that require detailed design, certification or project-specific analysis.
What technical validation means in manufacturing CPQ
Technical validation evaluates a configured product against the product model and the engineering knowledge encoded in that model. The model describes available options, parameters, components, dependencies, constraints, calculations and output rules. Validation uses this information to determine whether the selected configuration is acceptable.
A simple rule might prevent a stainless-steel pump casing from being paired with an incompatible seal material. A more advanced rule might calculate required motor power from flow, pressure, fluid density and efficiency, then restrict the available motor family to units that meet the result. The first is an option compatibility rule; the second is an engineering calculation combined with a selection constraint.
Technical validation normally covers several dimensions:
- Configuration validity: selected features and options are compatible.
- Dimensional validity: lengths, widths, heights, clearances and connection sizes fall within allowable ranges.
- Functional validity: the product can meet the requested performance, capacity or operating conditions.
- Material validity: materials, coatings and components are suitable for the application or environment.
- Manufacturing validity: the configuration can be produced using available processes, equipment and approved components.
- Documentation validity: the data required for drawings, specifications, BOMs and work instructions is complete.
- Commercial validity: cost, lead time, pricing and approval conditions can be calculated from a technically valid configuration.
These checks belong primarily to product configuration and rules management, but their outputs affect pricing, quoting, CAD automation, BOM generation, ERP transactions and engineering workflows.
Why technical validation matters for a CPQ configurator
Generic sales CPQ often focuses on selecting a package, applying discounts and generating a proposal. Manufacturing CPQ must usually establish whether the proposed product can actually be built and delivered. The difference is important when products contain engineered dimensions, optional assemblies, performance calculations or customer-specific designs.
Without technical validation, a sales engineer may create a quote for a machine with an impossible combination of frame size, motor, guarding and conveyor length. The problem may not be discovered until an application engineer reviews the order. At that point, the company may need to revise the price, request new drawings, change the delivery date or return to the customer for clarification.
Validation moves appropriate checks earlier in the workflow. It can provide an immediate error, warning or recommendation while the configuration is still being edited. For example:
- An error can prevent a 460-volt motor from being selected for a control system designed only for 230 volts.
- A warning can indicate that a selected stainless-steel finish may increase lead time.
- A recommendation can suggest a larger heat exchanger when the calculated thermal load exceeds the standard range.
- An engineering review status can be assigned when the configuration passes standard rules but requires project-specific analysis.
Validation therefore improves the quality of the handoff from sales to engineering. It does not mean that every decision should be automated or that every product should be treated as fully configurable.
The product model behind technical validation
Technical validation depends on a structured product model. The model should represent the product in terms that can be understood by sales, engineering, manufacturing and the connected enterprise systems.
Features, options and parameters
Features describe configurable areas of a product, such as drive system, enclosure, mounting arrangement or control package. Options are the available choices within those features. Parameters are values entered or calculated during configuration, such as tank diameter, flow rate, lifting capacity or cable length.
For an industrial pump, the model might contain:
- pump type and impeller family;
- flow rate and discharge head;
- fluid temperature and viscosity;
- casing and impeller material;
- shaft seal type;
- motor voltage, frequency and power;
- base, coupling and guard options;
- connection size and orientation.
Validation rules use these values to determine which options remain available and what calculations must be performed.
Dependencies and constraints
A dependency describes a relationship between product elements. A constraint limits the combinations or values that are allowed. For example, a high-temperature fluid condition may require a particular seal family. A large impeller may require a larger casing. A 12-metre conveyor may require an intermediate support structure.
Constraints can be expressed as allowed combinations, prohibited combinations, ranges, required selections or conditional requirements. They may also depend on plant, market, regulatory region, product revision or manufacturing method.
It is useful to distinguish three related approaches:
| Approach | Purpose | Manufacturing example |
|---|---|---|
| Rules-based configuration | Applies explicit if-then logic and option dependencies. | If a hazardous-area motor is selected, require the matching certified enclosure and documentation. |
| Constraint-based configuration | Finds or restricts solutions within technical limits and relationships. | Select a heat exchanger and fan combination that satisfies airflow and thermal capacity limits. |
| Guided selling | Uses questions and recommendations to help a user reach a suitable product. | Ask about room size, operating temperature and airflow before presenting HVAC unit options. |
These approaches can coexist, but guided selling alone is not technical validation. A guided selling questionnaire may lead a user toward a product family, while rules and engineering calculations determine whether the final configuration is valid.
Types of technical validation checks
Compatibility validation
Compatibility validation checks whether selected components can operate together. Examples include a motor and gearbox combination, a valve body and actuator, a truck chassis and body module, or an electrical enclosure and control hardware.
Compatibility can be simple, such as a direct option dependency, or complex, such as checking voltage, current, environmental rating, connector type and available mounting space across several assemblies.
Range and dimensional validation
Range validation checks whether values fall within approved limits. A configurable pressure vessel may accept a diameter from one range and a wall thickness from another. A machine enclosure may require minimum clearance around moving parts. A conveyor length may be limited by the selected frame profile and support spacing.
Dimensional checks should account for units, tolerances, reference datums and rounding. A model that accepts metric and imperial inputs must define how conversions are handled and how values are stored for downstream systems.
Performance and engineering calculations
Some products require calculated values rather than simple option checks. A pump configuration may calculate hydraulic power. An HVAC unit may calculate capacity from airflow, entering temperature and leaving temperature. A lifting device may compare rated load, reach and duty cycle. An electrical system may calculate current, heat dissipation or enclosure requirements.
Calculation logic should identify its inputs, formulas, units, assumptions, valid ranges and output actions. If a calculation is outside its validated operating range, the system should not silently produce a result. It should raise an exception, request engineering review or prevent completion.
Material and application validation
Material rules connect the customer application to approved product materials. Fluid chemistry, temperature, corrosion exposure, hygiene requirements and outdoor installation can influence casing, seals, coatings, fasteners and insulation.
For example, selecting a corrosive chemical may exclude a standard elastomer and require a different seal material. The rule should also identify whether the replacement affects price, lead time, procurement codes, drawings or certification documents.
Manufacturing and supply validation
A technically feasible product may still be unsuitable for a specific plant or supply chain. Manufacturing validation can check whether a component is approved for a plant, whether a fabrication process supports the requested dimension, or whether a selected component is obsolete or temporarily unavailable.
These checks often require data from enterprise systems. Enterprise Resource Planning (ERP) systems may provide item status, plant data and purchasing information. Product Lifecycle Management (PLM) or Product Data Management (PDM) systems may provide released revisions and approved structures. A CPQ platform should not be treated as the authoritative source for all of this information unless the architecture explicitly makes it so.
Validation outputs: errors, warnings, recommendations and reviews
Not every issue should block configuration. A useful validation design distinguishes the severity and action associated with each result.
| Output | Meaning | Example |
|---|---|---|
| Error | The configuration cannot be completed or released. | The selected motor does not meet the calculated load requirement. |
| Warning | The configuration is possible but requires attention or acceptance. | The requested paint system is available only at a longer lead time. |
| Recommendation | An alternative may improve technical or commercial suitability. | Recommend a larger frame to provide additional service margin. |
| Engineering review | The standard model cannot fully determine suitability. | A custom support structure is needed for an unusual installation. |
| Information | Provides context without changing validity. | Shows the calculated operating point and selected design margin. |
Each result should have an owner and a defined resolution. A vague message such as configuration invalid is difficult for sales and engineering teams to use. A better message identifies the condition, the affected selection and the next action, such as select a motor rated at least 15 kilowatts or submit the configuration for application engineering review.
Relationship between validation, BOM, CAD and pricing
Technical validation is a central point in the flow from customer requirements to production data, but it is not the same as BOM generation, CAD automation or pricing.
- Validation determines whether the configuration satisfies defined technical and business conditions.
- BOM generation determines which components and quantities are associated with the valid configuration.
- CAD automation creates or updates geometry, models, drawings or layouts when supported by the architecture.
- Costing and pricing calculate internal cost, customer price, margin, discounts and commercial approvals.
- Quoting presents the commercial result, scope, assumptions, lead time and terms to the customer.
A valid configuration may generate a configurable BOM without generating a finished CAD model. Conversely, a CAD system may create geometry while the CPQ model still lacks complete costing or manufacturing logic. These capabilities should be evaluated separately. See the guide to BOM generation, pricing and quote automation and the guide to CAD and engineering automation for their distinct roles.
EBOM, MBOM and configurable BOM
An Engineering Bill of Materials (EBOM) describes a product from an engineering design perspective. A Manufacturing Bill of Materials (MBOM) represents how the product is assembled or produced, including manufacturing-specific structures, operations or consumables. A configurable BOM is a structure that changes according to selected options, parameters and rules.
Technical validation may operate before BOM generation, during component selection or after a preliminary BOM is produced. For example, the configuration may validate the chosen motor family first, then select the exact item number and quantity for the configurable BOM. An ERP or manufacturing system may later transform that structure into an MBOM or production order.
Where validation fits in the manufacturing workflow
A typical workflow begins when a salesperson, dealer, sales engineer or customer enters requirements into the CPQ configurator. The system applies product rules, performs calculations and identifies invalid selections. When the configuration passes the required checks, it can calculate cost and price, generate a quote and prepare downstream data.
- Capture customer requirements and operating conditions.
- Select the product family and required features.
- Apply dependencies, exclusions and value ranges.
- Run engineering calculations and technical constraints.
- Generate validation messages and resolve exceptions.
- Determine the configured BOM, options, documentation and possible CAD outputs.
- Calculate cost, price, margin and lead-time implications.
- Route non-standard or incomplete cases to engineering approval.
- Create the quote and, after acceptance, transfer approved data to ERP, PLM, CAD or manufacturing systems.
In Configure-to-Order (CTO), validation usually selects from an established product model and released components. In Engineer-to-Order (ETO), validation may identify the boundary between standard configuration and work that requires engineering design. Make-to-Order (MTO) and Assemble-to-Order (ATO) processes may use similar checks, but their item, routing and production-data requirements differ. The related manufacturing workflow guide explains these distinctions.
Maintainability of validation rules
A technically correct rule can still become a long-term problem if nobody can maintain it. Product models often outlive the original implementation team, and rules change when products, suppliers, plants, standards and engineering policies change.
Manufacturers should maintain a clear ownership model. Product management may own feature definitions, engineering may own technical constraints, manufacturing may own plant-specific rules, supply chain may own sourcing restrictions and commercial teams may own approval thresholds. A governance process must resolve conflicts between these owners.
Useful maintenance practices include:
- store rules in readable, named units rather than one large block of opaque logic;
- separate product structure, technical constraints, pricing and workflow approvals;
- record the source, owner, revision and effective date of important rules;
- use version control for product models and released configurations;
- define units, tolerances, rounding and calculation precision explicitly;
- test normal, boundary, invalid and exception cases;
- retain known-good configurations as regression tests;
- review rules when components become obsolete or engineering standards change;
- monitor validation failures to identify unclear requirements or missing model logic.
Rule maintainability is a major selection criterion when evaluating manufacturing CPQ and product configuration software. A platform may demonstrate powerful configuration functions but still be difficult to govern at the scale of a large industrial product portfolio.
Implementation considerations
Start with decision-critical rules
Do not attempt to encode every engineering fact at once. Begin with rules that prevent expensive or frequent errors, such as incompatible voltage selections, impossible dimensions, missing required assemblies and invalid operating ranges. Expand the model after the initial rule set is tested in real quoting workflows.
Define the authoritative source for each data type
The CPQ application may own the sellable option model, while PLM owns released engineering revisions, ERP owns item and plant data, Customer Relationship Management (CRM) stores the opportunity and customer context, and CAD owns detailed geometry. Product Information Management (PIM) may manage descriptive and channel content, while a Manufacturing Execution System (MES) manages shop-floor execution. These systems are related but not interchangeable.
Integration decisions should define which system creates, approves, updates and consumes each data object. The CPQ integration guide provides a framework for separating these responsibilities.
Test rules with engineering scenarios
Testing should use representative products and real configuration paths. Include minimum and maximum dimensions, incompatible materials, unusual but valid combinations, obsolete items, unit conversions, missing data and transitions between product revisions. Test both the user experience and the downstream output. A configuration that displays no error but creates an incomplete BOM is not technically validated.
Plan for human review
Some cases cannot be safely automated. Define when the system should stop, what evidence the engineer receives, which fields can be changed and how the approved result returns to the quote. A controlled engineering review is preferable to allowing users to bypass a rule without traceability.
Implementation planning should cover data migration, ownership, release management, testing, adoption and ongoing support. The CPQ implementation guide covers these activities in more detail.
Limitations and common failure modes
Technical validation is only as reliable as the product data, rules and assumptions behind it. Common failure modes include:
- Incomplete product knowledge: undocumented engineering exceptions remain outside the model.
- Stale data: obsolete components or unreleased revisions remain selectable.
- Overly broad rules: a rule blocks valid configurations because it does not account for a legitimate exception.
- Overly narrow rules: the model accepts a combination that fails under actual operating conditions.
- Hidden calculations: users cannot understand why a value or option was selected.
- System duplication: the same rule is implemented differently in CPQ, ERP and CAD.
- False certainty: a green validation result is treated as a guarantee of full engineering suitability.
- Weak exception handling: users bypass warnings or create uncontrolled manual changes.
Validation should therefore communicate its scope. It can confirm that a configuration satisfies modeled rules, but it may not confirm site conditions, regulatory approval, installation quality, supplier performance or every aspect of detailed design.
How to evaluate technical validation in a CPQ platform
When comparing platforms, ask vendors to demonstrate a real manufacturing scenario rather than a generic option-selection screen. Useful evaluation questions include:
- Can the model handle numeric parameters, ranges, units and tolerances?
- Can rules express dependencies across multiple assemblies?
- Can the system perform engineering calculations, and how are formulas tested?
- Can validation produce errors, warnings, recommendations and engineering-review states?
- Can the platform distinguish configured items, EBOM structures and MBOM requirements?
- How are product revisions, effective dates and plant-specific rules managed?
- Can rules be maintained by authorized business and engineering users?
- How are validation results exposed through APIs or integrations?
- What happens when ERP, PLM, PDM or CAD data is unavailable?
- Can the system preserve an auditable record of the rules and revisions used for a quote?
These questions help distinguish a manufacturing product configurator from a quoting application that only handles bundles, discounts and proposal documents.
Conclusion
Technical validation is the control layer that connects product configuration with engineering reality. It checks options, parameters, dimensions, materials, calculations, manufacturing constraints and required outputs before a configured product proceeds to pricing, quoting or production.
Reliable validation requires more than a collection of if-then statements. It depends on a maintainable product model, authoritative data, clear rule ownership, tested calculations, controlled exceptions and appropriate integration with ERP, PLM, PDM, CAD and manufacturing systems. When implemented carefully, a CPQ configurator can prevent predictable configuration errors while still routing genuinely novel or high-risk products to engineering review.
Semantic map
The main entities and relationships covered in this guide are:
- CPQ configurator → applies → product configuration rules
- Product model → contains → features, options, parameters and constraints
- Technical validation → checks → compatibility, dimensions, materials and performance
- Engineering calculation → produces → technical requirement or selection result
- Configuration rule → prevents → invalid product combination
- Valid configuration → generates → configurable BOM
- Configurable BOM → can be transformed into → manufacturing BOM
- Valid configuration → supports → pricing and quote generation
- CAD automation → uses → configured dimensions and selections
- CPQ → exchanges product and order data with → ERP
- CPQ → exchanges released product data with → PLM or PDM
- Exception handling → routes non-standard cases to → engineering review
- CTO workflow → uses → released product rules
- ETO workflow → identifies → work requiring engineering design
- Rule governance → maintains → product model accuracy
Frequently asked questions
1. What is technical validation during product configuration?
It is the process of checking whether a proposed product satisfies defined technical, dimensional, material, performance and manufacturing rules before it is quoted or released.
2. Is technical validation the same as product configuration?
No. Product configuration selects and defines the product. Technical validation checks whether the selected values and options form a valid and usable product.
3. How does a CPQ configurator validate a product?
It evaluates rules, dependencies, constraints, parameter ranges and, where supported, engineering calculations against the selections entered by the user.
4. What is an example of a technical validation rule?
A rule might require a larger motor when calculated pump power exceeds the rating of the selected motor family, or prevent a material from being used with an incompatible fluid.
5. Can technical validation check dimensions?
Yes, if the product model includes dimensional parameters, units, allowable ranges, tolerances and the relationships between dimensions and components.
6. Does every CPQ platform support engineering calculations?
No. Some platforms support formulas or constraint logic, while others require a separate engineering calculation service or integration with specialist software.
7. Does a valid configuration automatically produce a BOM?
No. BOM generation is a separate capability. A platform may validate a configuration without generating an Engineering BOM, Manufacturing BOM or configurable BOM.
8. What is the difference between a configurable BOM and an MBOM?
A configurable BOM changes according to product selections. A Manufacturing BOM represents how the selected product is structured and produced in a manufacturing environment.
9. Can validation replace engineering review?
No. It can automate known and repeatable checks, but unusual applications, certification requirements and new designs may still require engineering review.
10. What should happen when a configuration fails validation?
The system should identify the failed condition, affected selection and corrective action. It may block the configuration, suggest an alternative or route the case for engineering approval.
11. What is the difference between an error and a warning?
An error normally prevents completion or release. A warning indicates a condition that may be acceptable but requires attention, acknowledgement or further review.
12. How are technical validation rules maintained?
Rules should have named owners, documented sources, version control, effective dates, regression tests and a formal process for product and engineering changes.
13. Which systems provide data for validation?
Depending on the architecture, CPQ may use product data from PLM or PDM, item and plant data from ERP, geometry from CAD and customer context from CRM.
14. Can validation include supply-chain restrictions?
Yes, a model can check approved suppliers, plant availability, obsolete items or sourcing restrictions when that information is available and current.
15. How does validation support configure-to-order manufacturing?
It ensures that the selected configuration stays within the approved product model and can be built from released components and defined manufacturing structures.
16. How does validation support engineer-to-order manufacturing?
It can identify which requirements fall outside the standard model and create a controlled engineering-review path instead of allowing an unsupported configuration to proceed as standard.
17. Why are units and tolerances important?
Inconsistent units, rounding or tolerances can produce incorrect calculations and false validation results, especially for dimensions, pressure, temperature, flow and electrical values.
18. What should manufacturers demonstrate when evaluating a CPQ platform?
They should demonstrate a real product scenario involving numeric parameters, dependencies, engineering calculations, validation messages, BOM outputs, revisions and downstream system handoffs.