Tag: engineering calculations

How to Build a CPQ Product Model for Manufacturing

A CPQ product model is the structured definition of a configurable product used by a Configure, Price, Quote system. In manufacturing, it describes the product hierarchy, selectable options, engineering parameters, configuration rules, calculations, prices and downstream outputs needed to produce a valid quote and, where supported, a bill of materials (BOM), CAD configuration or production order.

Building a reliable model starts with the product and its engineering logic, not with a list of sales questions. The model should represent how the product is actually designed, priced, manufactured and supported. A pump model, for example, may need to validate flow, head, fluid properties, motor size, impeller diameter, materials, seal type, voltage and certification requirements before it can produce a price or manufacturing-ready result.

This guide explains how to design a maintainable manufacturing CPQ product model, how to separate configuration rules from pricing, how to connect the model to BOM and CAD processes, and how to test and govern it over time.

What is a CPQ product model?

A CPQ product model is a machine-readable representation of a configurable product and the logic that determines which configurations are valid, what they cost and what data should be generated. It normally combines product structure, attributes, options, dependencies, constraints, calculations and outputs.

In generic sales CPQ, a product model may mainly determine which commercial products can be selected together and how discounts are calculated. A manufacturing CPQ model usually goes further. It may also need to capture dimensions, materials, performance requirements, engineering formulas, component substitutions, manufacturing choices, assembly relationships and references to product data managed in other systems.

Model element	Purpose in manufacturing CPQ	Example
Product hierarchy	Organizes the configurable assembly and its modules	Conveyor system, drive unit, belt, guards and controls
Options and attributes	Captures choices or values selected by a user	Belt width, frame material, motor voltage
Rules and constraints	Prevents invalid or unsafe combinations	A high-temperature seal is required for a specified fluid temperature
Engineering calculations	Derives sizes, ratings or performance values	Motor power calculated from load, speed and incline
Commercial logic	Calculates cost, price, discounts and surcharges	Price adjusted for stainless steel and a hazardous-area motor
Downstream outputs	Provides data to quoting, engineering and production	Configurable BOM, CAD parameters and ERP item references

The model is therefore more than a product catalog. It is a controlled product knowledge base that connects commercial configuration with engineering and manufacturing processes.

See the related guide to product configuration and configuration rules for a broader explanation of options, dependencies and validation.

Why product-model design matters

A poorly designed model can produce valid-looking quotes for products that cannot be built, priced profitably or supported by engineering. It may also become difficult to change when product managers add options, when suppliers change components or when engineering revises a design.

A well-designed model provides a controlled path from customer requirements to an approved configuration. It can reduce manual interpretation by sales engineers, expose missing information early and create consistent data for later systems. However, CPQ does not automatically create accurate engineering logic. The quality of the result depends on the source product data, rule ownership, integration design and testing discipline.

The main layers of a manufacturing CPQ product model

1. Product structure

Begin by representing the product as a hierarchy of assemblies, modules and components. The hierarchy should reflect how the product is configured and, where useful, how it is engineered or assembled.

For an industrial air-handling unit, the structure might include the base unit, casing, fan section, filters, heating or cooling coil, controls, electrical package and accessories. Each module can have its own options, rules, calculations and output mappings.

Do not assume that the sales structure, engineering structure and manufacturing structure are identical. A sales user may select one option called a heating package, while the engineering or manufacturing output may contain a coil, valves, sensors, control panels, wiring and mounting hardware. The model should make these relationships explicit rather than forcing users to select every internal component manually.

2. Options and attributes

Options are discrete choices, such as cast iron or stainless steel. Attributes are values that may be entered or calculated, such as length, flow rate, operating temperature or enclosure rating.

Each attribute should have a defined data type, unit, allowed range, default behavior and ownership. A dimension should not be stored as unstructured text if it is used in calculations or CAD automation. Similarly, a material should use a controlled value connected to a material record or code rather than several free-text spellings.

Data type	Manufacturing example	Design consideration
Enumeration	Motor type: standard, brake, inverter-duty	Use controlled values with stable identifiers
Numeric value	Tank volume: 500 litres	Store units, precision and valid range
Boolean	Include access platform: yes or no	Define default and downstream effect
Text	Customer marking or project reference	Keep free text out of engineering logic where possible
Calculated value	Required shaft diameter	Document formula, inputs and rounding rules

3. Dependencies

Dependencies describe relationships between selections. If a customer selects a diesel engine, the model may show compatible exhaust, cooling and fuel-system options. If a product includes a hygienic stainless-steel frame, certain surface finishes and fasteners may become available while painted-steel options become unavailable.

Dependencies should be expressed in terms of stable product data rather than interface labels. The rule should refer to an option identifier or attribute value that remains consistent if the wording shown to users changes.

4. Constraints

Constraints define what is permitted, required, excluded or conditionally available. Common types include:

Compatibility constraints: two components cannot be used together.
Requirement constraints: selecting one option requires another option.
Range constraints: a value must remain within a technically valid range.
Capacity constraints: a selected motor, frame or power supply must support the calculated load.
Process constraints: a configuration must follow manufacturing or installation limitations.
Regulatory constraints: materials, safety devices or certifications are required for a market or application.

For example, a valve model may permit a 250-millimetre diameter only when the pressure class and body material support it. A pump model may reject an impeller diameter if the requested duty point falls outside the operating envelope. A mobile machine may require a specific braking package when gross vehicle weight exceeds a threshold.

5. Calculations

Engineering calculations transform requirements into derived values. They can size a component, determine a performance rating, select a standard part or calculate a surcharge. Examples include pressure drop, heat-transfer area, belt length, battery capacity, structural load, motor power and cable size.

Calculation inputs should be clearly identified and validated before the calculation runs. The model should also record units, assumptions, rounding and the source of the formula. A formula copied from a spreadsheet without documenting its variables and limits is difficult to verify and maintain.

Not every CPQ platform includes a full engineering calculation engine. Some systems rely on external services, CAD rules, engineering applications or custom code. The architecture should make this boundary explicit.

6. Output mappings

Output mappings connect configuration decisions to commercial and technical results. A selected option may map to a component number, a BOM quantity, an operation, a price condition, a CAD parameter, an ERP material code or a document section.

One customer-facing option can produce multiple outputs. Selecting a stainless-steel pump package may change the casing material, fastener set, seal, baseplate finish, BOM components, cost, lead-time message and technical description.

Start with a product-model scope

Before building rules, define the product family and the business process the model must support. A first release should have a clear boundary. Trying to model every product variant, legacy exception and engineering possibility at once usually produces unclear ownership and excessive testing effort.

Document:

the product family and included modules;
the intended users, such as sales, dealers, application engineers or customers;
the workflow, such as configure-to-order (CTO), engineer-to-order (ETO), make-to-order (MTO) or assemble-to-order (ATO);
the required outputs, such as price, quote text, configurable BOM or CAD parameters;
the systems that own item, revision, customer and commercial data;
the approval points and conditions that require engineering review.

CTO means configure-to-order: the product is assembled from predefined options and components. ETO means engineer-to-order: a customer requirement leads to additional engineering work or a new design. MTO means make-to-order: production begins after a customer order rather than from stock. ATO means assemble-to-order: standard modules are assembled into a customer-selected combination. One product family can support more than one of these patterns, but the model should identify when a configuration remains within standard rules and when it becomes an engineering case.

Separate configuration, pricing and quoting logic

Configuration determines whether and how a product can be built. Pricing determines its commercial value. Quoting determines how the result is presented, approved and communicated. These concerns interact but should not be confused.

For example, a pump configuration rule may require a mechanical seal for a particular fluid. The pricing logic then adds the seal cost and applicable margin. The quote may display the seal as part of the selected package or as a technical inclusion. Combining all three concerns in one large rule makes changes risky.

Concern	Question answered	Example
Configuration	Is this product definition valid?	Can this impeller be used with this casing?
Engineering	What size or technical result is required?	What motor rating meets the duty point?
Costing	What does the configuration cost to produce?	What is the material and labor cost?
Pricing	What should the customer be charged?	What price, discount and surcharge apply?
Quoting	How should the offer be presented and approved?	Which descriptions, terms and documents appear?

This separation makes it easier to change a price list without rewriting engineering rules, or to revise a component relationship without altering quote templates.

Design rules for maintainability

Use modular rule groups

Organize rules by product module, function or decision type. Examples include motor compatibility, pressure rating, material selection, electrical requirements and documentation. Modular rules are easier to test than a single collection of nested conditions covering the whole product.

Prefer declarative rules where practical

A declarative rule states what must be true, such as a 480-volt motor requires a compatible control panel. This is generally easier for product experts to review than deeply embedded procedural code. Custom code may still be appropriate for complex calculations, external lookups or specialized engineering algorithms, but it should have an owner, test cases and version control.

Use controlled vocabularies

Materials, voltage classes, pressure ratings, regions, certifications and component types should use governed values. Controlled vocabularies reduce duplicate values and make integrations more reliable. They also help distinguish a commercial label from an engineering identifier.

Make defaults explainable

Defaults can reduce configuration time, but an incorrect default can create a hidden engineering or commercial error. Document why a default exists and whether the user may override it. For example, a standard motor may be preselected based on a typical duty, but the model should require confirmation when the calculated load exceeds the standard assumption.

Do not encode every exception as a normal option

Some requests are genuine ETO cases. If the model turns every historical exception into a selectable option, the product model becomes difficult to understand and test. Define an escalation path for nonstandard requirements instead of allowing invalid combinations through informal overrides.

Build the model from authoritative product data

A product model needs reliable source data. Typical sources include engineering specifications, product catalogs, drawings, bills of material, CAD parameters, price lists, costing sheets, ERP item masters and product lifecycle management (PLM) records.

PLM manages product definitions, revisions and engineering lifecycle information. Product data management (PDM) commonly focuses on controlled engineering files and relationships. Enterprise resource planning (ERP) manages business transactions such as items, inventory, purchasing, production and orders. Product information management (PIM) manages product content for channels and catalogs. These systems are related but are not interchangeable sources for every model element.

Before importing data, identify the system of record for each field. An ERP may own sellable item numbers and costs, while PLM owns engineering revisions and CAD relationships. A CPQ model may need synchronized copies of both, with explicit effective dates and revision behavior.

Data	Possible system of record	CPQ use
Engineering revision	PLM or PDM	Validate revision-specific options and outputs
Sellable item and inventory status	ERP	Map selected components and check availability rules
CAD family and parameters	CAD or PLM	Drive geometry or generate drawings where supported
Channel description and images	PIM	Present product information to users
Cost and price conditions	ERP, pricing service or CPQ	Calculate cost, price and margin

Connect the model to BOM, CAD and manufacturing outputs

Configurable BOMs

A configurable BOM is a bill of materials whose components or quantities depend on the selected configuration. The output may be a structured BOM for review, an ERP order structure, a manufacturing BOM (MBOM) or an engineering BOM (EBOM).

An EBOM represents the product from an engineering design perspective. An MBOM represents how the product is built, including manufacturing assemblies, consumables or process-specific items. They may not have the same structure. A CPQ system should not automatically treat a sales configuration output as a complete production BOM unless the mapping and approval process support that use.

For example, an air-handling unit may have one commercial heating option, an engineering assembly containing a coil and control valve, and an MBOM containing installation hardware and production operations. The product model should identify which output is being generated and which system is responsible for final validation.

CAD and engineering automation

Some manufacturing CPQ platforms connect configuration values to parametric CAD, drawing templates or engineering calculation tools. A selected tank diameter might drive a CAD parameter, while a calculated nozzle position might be passed to a design automation service.

CAD automation should be treated as a separate capability from basic CPQ. A system may support product rules and quoting without generating geometry. If CAD output is required, verify parameter mapping, revision control, regeneration behavior, drawing approvals and failure handling. More information is available in the guide to CAD and engineering automation in CPQ.

ERP and order handoff

ERP integration may transfer customer information, configured items, prices, BOMs, delivery information or order lines. The CPQ model must define which identifiers and revisions are sent, how errors are handled and whether ERP validates the result again.

CPQ should not be treated as a replacement for ERP, PLM, CAD or manufacturing execution system (MES) functionality. It is an orchestration and decision layer that may exchange data with these systems. The exact boundary depends on the platform and implementation.

Rules-based, constraint-based and guided configuration

These approaches overlap but are not identical.

Rules-based configuration uses explicit conditions such as if-then relationships, requirements, exclusions and calculations.
Constraint-based configuration describes valid combinations through constraints that a solver or rules engine evaluates, often across many variables.
Guided selling asks business or application questions and recommends suitable products or options. It may guide a user without representing the full engineering constraint system.

A guided selling flow might ask for required flow and pressure, then recommend a pump family. A constraint-based model may validate the resulting pump, motor, seal and materials across many interacting values. Guided selling can be a useful front end, but it does not by itself guarantee manufacturing validity.

Modeling a pump example

Consider a centrifugal pump sold for industrial water service. The model might contain the following inputs:

required flow and head;
fluid type, temperature and density;
casing and impeller material;
seal arrangement;
motor power, voltage and frequency;
connection size and pressure class;
baseplate and coupling requirements;
area classification or certification requirement.

The model could apply rules such as:

the selected impeller must meet the duty point within the approved operating range;
fluid temperature above a defined limit requires a suitable seal and gasket package;
the motor must meet the calculated power requirement with the required service factor;
the connection size must be compatible with the casing;
an area classification requires an approved motor and electrical package;
material and certification selections may trigger additional documentation and lead-time conditions.

The outputs might include a configuration summary, a price, a quote description, a component list, an engineering review flag and parameters for a pump datasheet. If the product falls outside the standard hydraulic range, the model should route it to application engineering rather than silently producing a standard quote.

Validation, testing and governance

Testing should cover more than individual rules. A model can pass isolated tests and still fail when several options interact. Create test cases from real product knowledge, historical quote errors, boundary conditions and known exceptions.

Test type	Purpose	Example
Positive test	Confirms a valid configuration is accepted	Standard pump with approved motor and seal
Negative test	Confirms an invalid configuration is rejected	Pressure class below the required operating pressure
Boundary test	Checks limits and unit handling	Maximum allowable temperature or flow
Interaction test	Checks combined rules	High temperature plus hazardous-area motor plus special material
Regression test	Ensures a change does not break existing behavior	New motor option does not alter existing BOM mappings
Output test	Confirms downstream data is correct	Configured components map to the correct ERP identifiers

Assign ownership for rules, calculations, prices, product descriptions, integrations and approvals. A product manager may own commercial options, engineering may own technical constraints, manufacturing may own MBOM mappings and finance may govern pricing policy. Shared governance is necessary because no single department owns the entire product model.

Use versioning and effective dates. A quote created under one product revision should remain traceable even after a new motor, material or price is introduced. Releases should include impact analysis, test evidence and a rollback or correction procedure.

Common product-modeling mistakes

Starting with the user interface: screens are designed before the product logic and data ownership are understood.
Using free text for structured engineering data: values cannot be validated or integrated reliably.
Mixing price and validity rules: discounts or surcharges accidentally make invalid products appear acceptable.
Copying spreadsheets without verification: hidden assumptions, obsolete formulas and manual overrides become embedded in the model.
Modeling only the happy path: edge cases, regional requirements and engineering review conditions are ignored.
Ignoring revisions: old quotes and new product definitions cannot be distinguished.
Assuming the CPQ BOM is production-ready: EBOM, MBOM and sales structures may require different mappings.
Allowing uncontrolled overrides: users bypass rules without recording who approved the exception.
Building one giant model: unrelated product families become difficult to test and govern.

Implementation sequence

Select a representative product family. Choose a product with meaningful configuration complexity and measurable business value.
Map the current process. Document how sales, application engineering, costing, design and production handle a quote today.
Inventory product data. Identify options, attributes, rules, formulas, components, revisions, prices and documents.
Define ownership. Assign responsibility for technical, commercial and downstream data.
Design the product hierarchy. Separate modules, standard options, calculated values and exceptions.
Implement core validity rules first. Prevent unsafe or impossible configurations before adding advanced presentation features.
Add calculations and outputs. Introduce sizing, pricing, quote content, BOM mappings and CAD or engineering interfaces as required.
Test with real scenarios. Include valid, invalid, boundary and historical cases.
Pilot with users and engineering. Confirm that questions are understandable and that outputs are useful downstream.
Release under governance. Version the model, document changes and monitor exceptions after deployment.

The detailed planning, migration, testing and governance topics are covered in the CPQ implementation guide.

How to measure product-model quality

Useful measures should reflect manufacturing outcomes rather than only interface activity. Possible measures include quote cycle time, percentage of configurations requiring rework, engineering review rate, invalid configuration rate, BOM correction rate, margin variance, quote-to-order conversion and the time required to implement a product change.

Interpret these measures carefully. A lower engineering review rate may mean the model handles standard products better, or it may mean users are bypassing review. A faster quote may still be poor if the price or BOM is inaccurate. Pair speed measures with quality, margin and downstream correction measures.

When a CPQ product model should stop

A product model should represent repeatable, governable product logic. It should not attempt to automate every engineering decision or replace professional approval for novel designs. Establish clear boundaries for standard configuration, configurable engineering and full ETO work.

For standard CTO products, the model may generate a validated BOM and pass parameters to ERP or CAD. For ETO products, it may capture requirements, calculate preliminary values, estimate price and create an engineering work request without claiming that the final design is complete. This distinction protects both the customer and the manufacturer.

Semantic map

The article connects the following manufacturing CPQ entities and relationships:

CPQ product model → represents → configurable product structure
Product options → define → customer-selectable choices
Configuration rules → prevent → invalid combinations
Engineering calculations → derive → technical product values
Configured product → produces → quote data
Configured product → can generate → configurable BOM
EBOM → represents → engineering product structure
MBOM → represents → manufacturing assembly structure
CAD automation → uses → configuration parameters
CPQ → exchanges data with → ERP
CPQ → may exchange revisions with → PLM or PDM
Pricing logic → calculates → customer price and margin
Manufacturing constraints → limit → valid product configurations
CTO workflow → uses → predefined product options
ETO workflow → escalates → nonstandard engineering requirements

Frequently asked questions

What is a CPQ product model?

A CPQ product model is the structured definition of a configurable product, including its hierarchy, options, attributes, rules, calculations, prices and downstream outputs.

How is a manufacturing CPQ model different from a sales CPQ catalog?

A manufacturing model may validate engineering constraints, calculate technical values and produce BOM, CAD or ERP data. A sales catalog usually focuses on selectable products, pricing and quote presentation.

What should be modeled first?

Start with the product structure, critical technical inputs and rules that distinguish valid from invalid configurations. Add pricing, documents and advanced outputs after the core product logic is understood.

Should every component appear as a customer-facing option?

No. Internal components should normally be derived from higher-level selections. Exposing every component increases user effort and creates more opportunities for invalid combinations.

What is the difference between an option and an attribute?

An option is usually a discrete choice, such as stainless steel or painted steel. An attribute is a value, such as length, flow, temperature or voltage.

How should engineering rules be represented?

Use explicit, modular rules with defined inputs, outputs, units, ownership and test cases. Declarative rules are often easier to maintain, while custom code may be needed for specialized calculations.

Can a CPQ product model calculate equipment size?

Some CPQ platforms support engineering calculations or connect to external calculation services. The capability must be verified for the required formulas, units, ranges, approvals and auditability.

Does every CPQ system generate a BOM?

No. BOM generation varies by platform and implementation. Confirm whether the system supports configurable BOMs and whether the output is a sales structure, EBOM, MBOM or ERP order structure.

Can a CPQ model generate CAD drawings?

Only when the platform or its integrations support CAD or design automation. Verify parameter mapping, geometry generation, revision control, drawing approval and failure handling.

What is the difference between EBOM and MBOM?

An EBOM describes the product from an engineering perspective. An MBOM describes how it is manufactured and may include production-specific assemblies, consumables or operations.

How does pricing relate to configuration rules?

Configuration rules determine whether a product is valid. Pricing logic calculates cost, price, discounts and surcharges for a valid configuration. Keeping these concerns separate improves maintainability.

How should ETO requirements be handled?

The model should capture requirements, identify what is outside the standard envelope and route the case to engineering. It should not present an unapproved design as a standard configuration.

Which systems provide data to a product model?

Possible sources include PLM or PDM for engineering definitions, ERP for items and costs, CAD for design parameters, PIM for channel content and pricing services for commercial conditions.

Who should own the product model?

Ownership is usually shared. Product management may own commercial structure, engineering technical rules, manufacturing BOM mappings and finance pricing policies. A governance process coordinates these owners.

How do you test a CPQ product model?

Test valid and invalid configurations, boundary values, interacting rules, calculations, revisions, pricing and downstream outputs. Use regression tests whenever a rule or product definition changes.

How often should a product model be updated?

Update it whenever product options, engineering rules, component revisions, prices, regulations or downstream mappings change. Releases should be versioned and tested rather than changed informally.

What is the biggest product-modeling mistake?

A common mistake is treating the model as a sales questionnaire instead of a controlled representation of product and manufacturing logic. This creates quotes that look complete but require engineering correction.

Can one CPQ model support CTO and ETO?

Yes, but the model must distinguish standard configurable paths from nonstandard engineering work. CTO may produce validated outputs directly, while ETO may generate an engineering request and preliminary commercial result.

How can manufacturers keep a product model maintainable?

Use modular rules, controlled data, clear ownership, documented calculations, versioning, automated regression tests and a defined process for exceptions and product changes.

October 16, 2026

CPQ CAD Automation: From Sales Inputs to Production Drawings

CPQ CAD automation connects a manufacturing Configure, Price, Quote (CPQ) system to computer-aided design (CAD) models so that approved sales inputs can produce product-specific engineering outputs. Depending on the implementation, those outputs may include a 3D model, 2D production drawing, engineering calculations, a configured bill of materials (BOM) or a handoff package for a product lifecycle management (PLM) or enterprise resource planning (ERP) system.

The purpose is not simply to draw a product faster. A well-designed process turns a valid product configuration into consistent engineering data. For example, a salesperson configuring a pump may select capacity, fluid, temperature, materials, motor type, seal arrangement, connection size and mounting orientation. The CPQ system validates those choices, calculates required dimensions, determines price and cost, and passes controlled parameters to CAD automation. CAD then generates the appropriate geometry and drawings for engineering review or production.

This is a manufacturing capability rather than a generic sales quoting feature. Not every CPQ platform supports CAD automation, engineering calculations, BOM generation or production drawings. Buyers must verify which functions are native, which require an external configurator or CAD automation service, and which remain under engineering control.

For a broader explanation of the product model and rules layer, see the guide to product configuration. For related engineering concepts, see CAD and engineering automation in CPQ.

What is CPQ CAD automation?

CPQ CAD automation is the controlled generation or modification of CAD data from validated product configuration data. The configuration normally begins with commercial or technical inputs, while the CAD output is governed by engineering parameters, templates, constraints and revision-controlled design assets.

A typical flow is:

A user selects a product family and enters required technical and commercial inputs.
The configuration engine applies rules and constraints to reject incompatible combinations.
Engineering calculations derive values such as shaft diameter, frame size, heat-transfer area, cable length or structural dimensions.
The CPQ system resolves a product structure and configurable BOM.
CAD automation maps approved parameters and component selections to CAD templates or parametric models.
The CAD process creates a model, drawing, PDF, neutral file or engineering package.
The resulting data is reviewed, versioned and transferred to downstream systems.

The output may be fully production-ready, suitable for engineering review, or only a sales visualization. These are different levels of automation and should not be treated as equivalent.

How manufacturing CPQ differs from generic sales CPQ

Generic sales CPQ often focuses on selecting options, calculating price and producing a proposal. Manufacturing CPQ may include those functions, but it also represents product structure, engineering constraints, component relationships, calculations, manufacturing data and downstream system identifiers.

Capability	Generic sales CPQ	Manufacturing CPQ with CAD automation
Configuration	Guided selection of sellable options	Technical configuration with dependencies, constraints and engineering parameters
Pricing	Prices, discounts and approvals	Pricing linked to materials, labor, operations, calculated dimensions and sourcing rules
Product output	Quote or proposal	Configuration, BOM, calculations, CAD files and production documentation where supported
Engineering handoff	Often a manual request or summary	Structured, validated data with model references, revisions and exception status
Workflow	Sales approval	Sales, engineering, manufacturing, ERP, PLM, PDM and sometimes MES coordination

CAD automation does not eliminate engineering responsibility. It moves repeatable design decisions into a controlled system and reserves expert review for exceptions, new designs, unusual loads, regulatory questions or configurations outside the approved model.

Reference architecture for CPQ CAD automation

A practical architecture normally contains several cooperating layers. They may be delivered by one platform or by multiple systems connected through application programming interfaces (APIs), files, queues or middleware.

1. Sales and user interface layer

This is where a salesperson, dealer, distributor, engineer or customer enters requirements. Inputs may include product family, dimensions, performance targets, materials, environment, compliance requirements, accessories and delivery preferences.

The interface should expose meaningful engineering inputs without requiring users to understand every internal part number. For example, a buyer may specify a required airflow and available installation space rather than selecting a fan motor and housing part number directly.

2. Product model and rules engine

The product model defines products, features, options, components, parameters and relationships. A rules engine evaluates dependencies and constraints. Rules may state that a stainless-steel wetted path is required for a specified chemical, that a motor must meet a voltage requirement, or that a frame cannot support a selected impeller diameter.

Rules-based configuration uses explicit conditions such as if-then logic. Constraint-based configuration describes allowable relationships and lets the engine find valid combinations. Guided selling recommends suitable products based on user requirements but may not provide complete engineering validation. These approaches can coexist, but they solve different problems.

More detail on options, dependencies and validation is available in the product configuration guide.

3. Calculation and engineering logic layer

Calculations convert requirements into design values. Examples include pressure-drop calculations for piping assemblies, thermal calculations for heat exchangers, load calculations for lifting equipment, enclosure sizing for electrical systems and power or torque calculations for machinery.

Calculation results may control both commercial and technical outputs. A calculated motor size can affect price, energy classification, BOM selection, mounting geometry and the drawing title block. Calculations should have defined inputs, units, valid ranges, formulas, tolerances and test cases.

4. CAD automation layer

The CAD layer applies configuration data to parametric parts, assemblies, templates or design rules. Automation may change dimensions, suppress or activate features, select components, create configurations, place standard parts, generate views and populate drawing metadata.

Some implementations use native CAD automation through an API. Others use a separate engineering configurator, a rules-based design automation application, a CAD server or a file-generation service. The integration method affects licensing, performance, security, concurrency and the level of control available to engineering.

5. BOM and manufacturing data layer

The system may generate a configurable BOM, an engineering bill of materials (EBOM) or a manufacturing bill of materials (MBOM). An EBOM describes the product from an engineering perspective. An MBOM describes how the product is assembled or manufactured, including operations, work centers, consumables or manufacturing-specific structure. A configurable BOM represents the possible or selected structure before it is resolved for a specific order.

CAD structure and manufacturing structure are related but are not always identical. A CAD assembly may contain reference geometry, fasteners or design groupings that should not appear in the MBOM. Conversely, manufacturing may require packaging, routing or consumable items that are not represented as modeled CAD components.

The BOM, pricing and quoting guide explains these relationships in more detail.

6. Document and enterprise integration layer

Approved results may be sent to ERP for order processing, inventory, purchasing and production control; to PLM for product definitions and revisions; to product data management (PDM) for CAD files and document control; to customer relationship management (CRM) for opportunity and account context; or to manufacturing execution systems (MES) for shop-floor execution.

These systems are not interchangeable. CRM manages customer and opportunity information. ERP manages business transactions and resource planning. PLM governs product lifecycle information. PDM commonly manages CAD files and revisions. MES manages manufacturing execution. CAD creates or modifies design data. A robust architecture defines which system owns each data object.

End-to-end data flow: from sales inputs to drawings

The most reliable implementations treat the process as a sequence of controlled transformations rather than a single button that produces a drawing.

Step 1: Capture requirements

The user enters requirements using business terminology. For a configured conveyor, this could include belt width, conveyor length, incline angle, product weight, throughput, environmental conditions, guarding and discharge direction.

Step 2: Normalize and validate inputs

The system converts units, checks ranges and identifies missing information. A length may be entered in millimeters while a legacy engineering formula expects meters. Unit conversion and precision rules must be explicit because small errors can affect both design and price.

Step 3: Resolve configuration rules

The engine selects valid options and rejects invalid combinations. For example, a high-temperature seal may require a specific material, exclude a standard elastomer and change the allowable operating speed.

Step 4: Run engineering calculations

Calculation services derive design parameters. The system should retain the calculation inputs, outputs, formula version and result status. This creates traceability when engineering reviews the design or a customer changes a requirement.

Step 5: Resolve the product structure

The configured product is mapped to component identifiers, quantities, descriptions, revisions and attributes. The result may include purchased parts, manufactured parts, optional accessories, raw materials and labor or operation references.

Step 6: Generate CAD and documents

CAD automation applies parameters to approved templates and assemblies. It may generate a 3D assembly, detail drawings, an arrangement drawing, a dimensional outline, a neutral exchange file or a PDF. Drawing metadata should be populated from governed product data rather than manually retyped.

Step 7: Apply review and release controls

Not every generated file should immediately become a released production document. The workflow may route results to an engineer for review, check model validity, compare against tolerances and assign a revision. A standard product may follow automatic release rules, while an ETO configuration may require detailed engineering approval.

Step 8: Transfer the approved package

The approved configuration, BOM, drawings and identifiers are sent to the relevant enterprise systems. The order should retain a reference to the exact configuration and design revision used to create the quote and production data.

Industrial example: configuring a centrifugal pump

Consider a pump manufacturer selling a configurable centrifugal pump. A sales engineer enters flow rate, differential pressure, fluid type, temperature, suction and discharge connection, materials, motor voltage, seal type, base arrangement and accessories.

The CPQ model may use those inputs to select a pump family and impeller range. A calculation determines an appropriate impeller diameter and motor rating. Rules prevent a material from being selected when it is incompatible with the fluid or temperature. The product structure then resolves the casing, impeller, shaft, seal, motor, coupling, base and fasteners.

CAD automation can update the pump assembly, place the selected motor, adjust the base dimensions, set connection orientation and generate an outline drawing. The resulting BOM may support ERP costing and purchasing, while the drawing may be sent to PLM or PDM for review and release.

There are important boundaries. If the selected duty point falls outside the validated pump family, the system should not create a falsely precise drawing. It should flag the configuration for engineering review or route it into an engineer-to-order (ETO) process.

CAD output levels and their limitations

Output level	Typical use	Important limitation
Sales visualization	Help a customer understand appearance, orientation or major options	May not contain manufacturing detail or verified dimensions
Configured 3D model	Support design review, layout and selected-product representation	May require engineering validation before release
Outline or arrangement drawing	Provide installation dimensions and interface information	May omit detail drawings, tolerances and manufacturing instructions
Production drawing package	Support manufacturing or procurement	Requires controlled templates, revision management, validation and release governance
Neutral CAD export	Exchange geometry with customers or downstream tools	Can lose parametric history, metadata or design intent

A generated drawing is not automatically a manufacturing-ready drawing. Production documentation may require tolerances, weld symbols, surface finishes, inspection requirements, material specifications, revision history and approval signatures. The automation scope must state which of these are generated and which are added during engineering release.

Benefits of connecting CPQ and CAD

Shorter sales-to-engineering handoff: structured parameters reduce re-entry from emails, spreadsheets and handwritten notes.
Fewer configuration errors: rules can prevent incompatible options before an order reaches engineering.
More consistent designs: approved templates and calculations reduce variation between engineers.
Faster quotation of engineered products: dimensions, components and calculations can contribute to cost and price.
Better customer communication: a configured model or drawing can clarify interfaces, orientation and space requirements.
Improved traceability: the organization can relate requirements, configuration, BOM, CAD revision and quote.
Reduced repetitive engineering work: engineers spend less time rebuilding standard or repeatable variants.

Key implementation challenges

Product model complexity

Product options are often documented inconsistently across CAD files, spreadsheets, ERP records and engineering knowledge. Before automation, the manufacturer must define product families, parameters, valid ranges, dependencies and ownership.

Rule ownership and change control

Rules affect design, cost, lead time and customer commitments. Engineering, product management, manufacturing and commercial teams should agree who can create, approve, test and retire rules.

CAD template quality

Automation magnifies weaknesses in templates. Unstable references, unmanaged file names, hard-coded dimensions and inconsistent metadata can cause failures at scale. CAD models intended for automation need predictable interfaces and documented parameters.

Revision and configuration identity

A quote may be revised after a drawing is generated. The implementation must identify the configuration version, calculation version, CAD template revision and released document revision. Otherwise, the organization may manufacture from a different design than the one priced.

Performance and exception handling

CAD generation can be computationally expensive, particularly for large assemblies or multiple quote alternatives. The architecture should define queues, timeouts, retries, error messages and manual fallback procedures.

ETO boundaries

Configure-to-order (CTO) selects from predefined and validated choices. Engineer-to-order creates or substantially modifies a design for a specific order. Make-to-order (MTO) triggers production after an order but may use a relatively standard product. Assemble-to-order (ATO) combines stocked modules after an order. CAD automation is usually most predictable for CTO and repeatable MTO products, while ETO requires stronger exception management and engineering review.

See the manufacturing workflows guide for a comparison of CTO, ETO, MTO and ATO processes.

Implementation approach

Select a narrow product family: begin with a product that has repeatable variants, meaningful configuration volume and reasonably stable CAD templates.
Document the current process: map sales inputs, engineering calculations, CAD steps, BOM creation, approvals and system handoffs.
Define system ownership: decide where product attributes, prices, CAD files, revisions, customers and manufacturing structures are maintained.
Separate rules from presentation: keep validation and engineering logic distinct from screen layout where possible.
Build a parameter contract: define names, units, data types, ranges, defaults, allowed values and ownership for every value passed to CAD.
Automate the BOM deliberately: document how CAD structure, EBOM, MBOM and ERP item records relate.
Test abnormal cases: include minimum and maximum dimensions, incompatible materials, missing data, obsolete components and failed CAD generation.
Introduce engineering gates: define when output is automatically accepted, when it requires review and when it must become an ETO request.
Measure operational results: monitor configuration error rates, engineering touch time, drawing cycle time, exception volume and revision-related rework.

The CPQ implementation guide covers governance, migration, testing, deployment and maintenance. Integration decisions are discussed in the CPQ integration guide.

How to evaluate a CPQ CAD automation capability

When assessing software, do not rely on a feature label such as CAD integration. Ask for a demonstration using representative product data and verify the complete path from input to released output.

Can the system represent dimensions, formulas, constraints and engineering dependencies?
Does it generate only visual output, or can it create controlled CAD and drawing files?
Which CAD systems, file types and automation interfaces are supported?
Can the system work with assemblies, configurations, family tables, templates and metadata?
How are CAD errors reported and resolved?
Can it generate a configurable BOM, EBOM or MBOM, and how are those structures reconciled?
How are revisions, approvals and configuration snapshots managed?
Can engineers override or review generated results without losing traceability?
How does the platform handle ETO exceptions?
What is native functionality and what requires custom development, middleware or a separate engineering tool?

Use the manufacturing CPQ comparison resources and CPQ software profiles to structure vendor research, but verify every capability against current product documentation and a product-specific proof of concept.

Semantic map

The following relationships summarize the entities and data flow discussed in this guide:

Sales requirements lead to a product configuration.
Configuration rules prevent invalid product combinations.
Engineering calculations derive design parameters.
A valid configuration resolves a configurable BOM.
CAD automation applies parameters to templates and assemblies.
CAD automation generates product-specific models and drawings.
An EBOM describes the engineered product structure.
An MBOM describes the manufacturing structure and operations.
PLM governs product lifecycle information and revisions.
PDM manages CAD files and document versions.
ERP uses approved product and order data for planning and transactions.
ETO exceptions require engineering review beyond the standard configuration model.

FAQ

1. What is CPQ CAD automation?

It is the automated use of validated CPQ configuration data to create or modify CAD models, assemblies, drawings or related engineering outputs for a configured manufactured product.

2. Does every CPQ system generate production drawings?

No. Some CPQ systems only manage options, pricing and quotes. CAD generation may require a dedicated integration, engineering configurator, CAD automation tool or custom development.

3. What inputs are needed for CAD automation?

Typical inputs include product family, dimensions, materials, performance values, component selections, interface requirements, calculated parameters and document metadata. Each input needs a defined unit, type and valid range.

4. Can CPQ create a 3D model?

Some manufacturing CPQ solutions can create or drive 3D models, while others only display prebuilt visualizations or pass data to an external CAD system. The distinction must be verified for the target CAD platform.

5. Is a 3D sales configurator the same as CAD automation?

No. A 3D configurator may change visual options for customer communication. CAD automation changes engineering geometry, parameters or documents and may require much stricter validation.

6. Can CPQ generate a BOM?

Some systems generate a configurable BOM or resolved product BOM. Whether that output is an EBOM, MBOM or ERP-ready structure depends on the data model and integration design.

7. What is the difference between an EBOM and an MBOM?

An EBOM represents the product as designed. An MBOM represents how the product is assembled or manufactured, including manufacturing-specific structure, operations or consumables.

8. How does CAD automation reduce engineering work?

It automates repeatable tasks such as selecting standard components, changing dimensions, positioning assemblies, creating views and populating drawing metadata. It does not replace engineering judgment for novel or exceptional designs.

9. Can CAD automation support engineer-to-order products?

It can support repeatable portions of an ETO process, but fully bespoke designs generally require engineering review, additional modeling and controlled exception management.

10. How are engineering calculations connected to CAD?

Calculation results are stored as controlled parameters and passed to CAD automation. For example, a calculated shaft diameter or frame length may drive model dimensions, component selection and drawing annotations.

11. What happens if the configuration is technically invalid?

The rules engine should block the combination, explain the conflict and request a valid alternative. If the requirement is outside the modeled range, it should route the case to engineering rather than generate an unsupported design.

12. Which system should own the CAD file?

Usually a PDM or PLM system owns controlled CAD documents and revisions, although the exact architecture varies. CPQ should normally reference the approved design rather than become the uncontrolled master repository.

13. How does CPQ CAD automation connect to ERP?

CPQ may send the configured item, BOM, quantities, prices, costs, lead-time attributes and document references to ERP. The interface must define identifiers, revisions, status and ownership for each data object.

14. Can CAD automation calculate product price?

It can provide dimensions, materials, components or operations that support costing. Price calculation normally belongs to the CPQ pricing layer, while CAD supplies selected engineering facts.

15. What CAD files can be generated?

Depending on the tools involved, outputs may include native part or assembly files, 2D drawings, PDFs, STEP or other neutral formats. Supported file types and metadata behavior must be verified for each implementation.

16. How should generated drawings be approved?

Use defined review and release gates. Standard validated configurations may follow automated checks, while new, high-risk or out-of-range designs should receive engineering approval before production release.

17. What is the biggest implementation risk?

A common risk is automating inconsistent product data and unstable CAD templates. The project should first establish a governed product model, clear rules, reliable templates and testable interfaces.

18. How should manufacturers start a CPQ CAD project?

Choose a repeatable product family, map the current sales-to-engineering process, define input and output ownership, build a limited proof of concept and test normal, boundary and exception configurations before expanding scope.

Related guides

September 17, 2026

Using Simulation and Engineering Calculations During Configuration

In manufacturing, simulation and engineering calculations allow a CPQ configurator to evaluate whether a proposed product will work before the quote reaches engineering or production. Instead of only selecting options and calculating a price, the system can calculate capacity, dimensions, performance, operating limits, material requirements and other technical results from the customer’s inputs.

For example, a pump configurator may use flow rate, head, fluid properties, temperature and motor requirements to recommend a suitable pump size. An industrial machinery configurator may calculate frame dimensions, drive power, lifting capacity or guarding requirements. The result can include a validated configuration, an engineering summary, a configurable bill of materials (BOM), product-specific CAD outputs and a quote based on technically feasible requirements.

This is a major distinction between manufacturing CPQ and generic sales CPQ. A sales-oriented system may configure commercial options and calculate a price. A manufacturing CPQ system may also execute engineering formulas, call simulation services, generate CAD data and pass validated product information to enterprise systems.

What are engineering calculations during configuration?

Engineering calculations during configuration are formulas, algorithms or external engineering services that transform configuration inputs into technical results. The results may determine whether a product is feasible, which components are required, how the product should be dimensioned or what performance it can deliver.

The calculation normally runs after, or during, a user’s configuration choices. It can use selected options, numeric dimensions, environmental conditions, material properties, product standards and data from a product model. The output may be a warning, a required option, a calculated value, a recommendation, a component selection, a CAD parameter or an approval requirement.

Calculation type	Typical inputs	Possible outputs
Capacity calculation	Load, flow, speed, volume or duty cycle	Required motor, frame size or rated capacity
Dimensional calculation	Length, width, height, clearance or installation space	Product dimensions, shaft length or enclosure size
Thermal calculation	Temperature, heat load, ambient conditions and materials	Cooling requirement, insulation class or derating
Hydraulic calculation	Flow, pressure, fluid density, viscosity and pipe geometry	Pipe diameter, pump selection or pressure loss
Electrical calculation	Voltage, current, power, phase and protection requirements	Cable size, breaker rating or control-panel components
Structural calculation	Loads, spans, materials, supports and safety factors	Section size, reinforcement or engineering review

These calculations do not always constitute a full physical simulation. A simple algebraic formula may be sufficient for product selection. More advanced cases may use finite element analysis, computational fluid dynamics, kinematic simulation or an external engineering application.

Where calculation fits in a manufacturing CPQ architecture

A calculation-driven configurator usually sits between product data, engineering logic and commercial processes. The CPQ system manages the customer-facing configuration and often coordinates the data exchange, while specialized systems may perform calculations or generate design outputs.

User inputs: The salesperson, dealer, engineer or customer enters requirements such as capacity, dimensions, material, operating environment and delivery constraints.
Configuration model: The CPQ product model applies options, dependencies, exclusions and constraints. It determines which selections are permitted.
Calculation engine: Formulas or an external service calculates technical values and evaluates performance or compliance.
Selection and validation: The system selects components, reports warnings and requests additional information where needed.
Engineering output: Parametric CAD, drawings, specifications, calculations or simulation results are generated when supported.
Commercial output: The calculated configuration drives costing, pricing, a quote and potentially approval workflows.
Manufacturing handoff: The validated configuration creates or updates a BOM, order structure and data sent to enterprise systems.

The surrounding systems have different responsibilities. CAD means computer-aided design and contains geometric or design information. A product lifecycle management system (PLM) manages product definitions, revisions and lifecycle processes. A product data management system (PDM) generally manages CAD files and related engineering data. An enterprise resource planning system (ERP) manages operational data such as items, inventory, purchasing, orders and production. A manufacturing execution system (MES) supports execution on the shop floor.

These systems are related but are not interchangeable. A CPQ system may orchestrate data between them through APIs, files, middleware or integration platforms. The appropriate architecture depends on where the authoritative version of each product and engineering record is maintained.

Rules, calculations and simulation are different capabilities

Product configuration rules, engineering calculations and simulation often work together, but they solve different problems.

Capability	Main question	Example
Rules-based configuration	Is this selection allowed?	A stainless-steel option requires a compatible seal material.
Constraint-based configuration	Which combinations satisfy multiple technical constraints?	The selected motor, voltage and enclosure must be compatible with available space and power requirements.
Guided selling	Which product or option should be recommended based on user needs?	Recommend a valve family based on media, pressure and temperature.
Engineering calculation	What technical value or component follows from the requirements?	Calculate required pump head or structural section size.
Simulation	How will the proposed design behave under modeled conditions?	Evaluate stress, airflow, motion or thermal performance.

A rule may prevent an invalid combination without calculating anything. A formula may calculate a result without modeling physical behavior in detail. A simulation usually represents more complex behavior and may require more inputs, longer processing time and specialist validation.

Manufacturing examples

Pump and fluid equipment configuration

A pump configurator can collect flow rate, total dynamic head, fluid type, temperature, viscosity, installation arrangement and power supply. Rules may prevent incompatible materials or seal combinations. Engineering calculations may estimate system resistance, pump duty point and motor power. A selection algorithm can identify suitable pump sizes from a controlled product catalog.

The result may include a pump assembly, motor, coupling, baseplate, seals, instrumentation and a configurable BOM. A CAD system may use the selected pump, nozzle orientation and base dimensions to produce a model or drawing. The price can incorporate the selected materials, motor size and engineering options.

HVAC and air-handling equipment

An air-handling unit configurator may calculate airflow, heating or cooling capacity, coil dimensions, fan selection and pressure drop. Inputs can include air volume, entering and leaving temperatures, humidity, altitude, filtration requirements and available installation space.

The calculation may identify a standard configuration, a non-standard design requiring engineering review or an infeasible request. It can also influence enclosure dimensions, access-panel positions, motor selection and the BOM. A quotation should make clear which results are calculated automatically and which remain subject to final engineering approval.

Industrial machinery

For a conveyor, hoist or packaging machine, configuration inputs may include product weight, throughput, travel distance, duty cycle, line speed and layout dimensions. Calculations can determine drive torque, motor power, belt width, roller spacing or frame requirements.

If the requested combination exceeds the standard design envelope, the CPQ system may route the opportunity into an engineer-to-order (ETO) process. ETO means that substantial engineering work is performed for a particular order. By contrast, configure-to-order (CTO) uses predefined choices and generally produces a standard or modular product.

Electrical equipment and enclosures

An electrical equipment configurator may calculate enclosure size, heat dissipation, cable-entry requirements, protective-device ratings and available panel space. Rules can enforce voltage, phase, short-circuit rating and component compatibility.

Where the design involves safety, regulatory compliance or high fault energy, automated results should be treated as decision support unless the organization has formally validated the calculation method and approval process.

Using simulation during configuration

Simulation is useful when a simple rule or formula cannot adequately predict product behavior. It may represent structural stress, airflow, fluid movement, heat transfer, motion, acoustics or energy consumption. In a CPQ workflow, simulation can be synchronous, asynchronous or performed after the initial configuration.

Synchronous simulation

A synchronous simulation runs while the user is configuring the product and returns a result before the workflow continues. This can provide immediate technical feedback, but it requires fast execution, a controlled model and reliable error handling. It is more appropriate for simplified calculations or reduced-order models than for computationally intensive analyses.

Asynchronous simulation

An asynchronous simulation runs as a background job. The CPQ system submits inputs, receives a job identifier and later retrieves the result. This approach supports more demanding analysis but requires status management, timeouts, notifications, version tracking and a clear user experience.

Simulation after configuration

Some companies allow a preliminary configuration and price to be created first, then run a detailed analysis before order acceptance. This is common when the analysis needs specialist software, licensed engineering tools or a controlled approval process. The commercial workflow should identify the quote as conditional if technical validation is incomplete.

CAD and 3D outputs from calculated configurations

Engineering calculations become more valuable when their outputs drive computer-aided design (CAD). A parametric CAD template can use calculated dimensions and selected options to create a product-specific model, drawing or visualization.

For example, a configured material-handling system may calculate conveyor length, support spacing and drive position. Those values can populate CAD parameters. The resulting model may show the selected arrangement, while a drawing generator adds dimensions, hole patterns, connection details and notes.

Possible outputs include:

3D product models for review or customer approval;
2D drawings with calculated dimensions;
installation layouts and clearance envelopes;
rendered images for a proposal;
neutral CAD exchange files;
engineering calculation reports;
manufacturing or assembly documentation.

Not every CPQ platform generates CAD. Some integrate with CAD automation software, while others only store a reference to an externally generated file. Buyers should verify which CAD systems are supported, how templates are governed, how revisions are controlled and whether generated files can be reproduced from the saved configuration.

For more detail, see the guide to CAD automation and engineering automation in manufacturing CPQ.

How calculations affect BOMs, costing and quotes

A bill of materials (BOM) lists the components, quantities and relationships required for a product or assembly. A calculated configuration can determine not only which options appear on a quote, but also which components are required for manufacturing.

A configurable BOM may contain rules such as:

selecting a motor based on calculated power;
adding reinforcement when a load exceeds a threshold;
changing material grades based on temperature or fluid compatibility;
adding sensors when a control option is selected;
changing fasteners, seals or coatings for an environmental condition;
selecting different subassemblies for a calculated size range.

An engineering BOM (EBOM) describes the product from an engineering and design perspective. A manufacturing BOM (MBOM) describes how the product is assembled or manufactured, including production structure and sometimes manufacturing-specific items. A CPQ process may generate or influence an EBOM, an MBOM, a configurable BOM or an order-specific structure, but the exact responsibility depends on the system architecture.

Calculated values can also affect costing and pricing. A larger motor, thicker material, additional reinforcement or custom machining may increase cost. However, technical calculation and commercial pricing should remain conceptually separate. The calculation determines what is technically required; the pricing engine determines how that requirement is valued commercially.

See BOM generation, costing and quote automation for the relationship between configuration outputs and commercial documents.

Managing the sales-to-engineering handoff

A strong configuration workflow reduces the amount of information engineering must reconstruct from a sales conversation. The handoff should include the customer requirements, selected options, calculated values, assumptions, warnings, approvals, revision identifiers and generated outputs.

For example, a sales engineer handing over a configured pressure system should not send only a product code and price. Engineering may also need fluid properties, design pressure, temperature, corrosion allowance, selected materials, calculated wall thickness, instrumentation requirements and the version of the calculation method used.

The handoff can be automatic for CTO products. For ETO products, the CPQ system may create an engineering request containing the preliminary design and identify the unresolved decisions. This preserves the work already performed while allowing an engineer to review non-standard requirements.

Manufacturing workflow concepts such as CTO, ETO, make-to-order (MTO) and assemble-to-order (ATO) are explained in the guide to manufacturing CPQ workflows.

Data required for reliable calculations

Calculation quality depends on the quality and governance of the underlying data. A calculation is not reliable merely because the formula is mathematically correct.

Input definitions: Units, permitted ranges, precision, default values and required fields must be explicit.
Engineering constants: Material properties, efficiency factors, safety factors and performance curves require controlled ownership.
Product data: Component ratings, dimensions, compatibility information and lifecycle status must be current.
Versioning: The system must identify which formula, product revision and engineering data produced a result.
Assumptions: Ambient conditions, duty cycles, installation factors and user-provided estimates should be visible.
Units and conversions: The system must prevent errors between metric and imperial units or between related engineering measures.
Validation ranges: Inputs should be checked for missing, implausible or contradictory values.

Product data may be maintained in the CPQ system, PLM, PDM, ERP or a specialist engineering database. The implementation should define which system is authoritative for each data category and how updates are published.

Benefits and limitations

Benefits

Fewer technically invalid quotes reach customers.
Sales engineers can evaluate standard configurations without repeating manual calculations.
Quotes can include more accurate dimensions, performance values and scope.
Calculated selections can drive BOMs, drawings and downstream order data.
Engineering effort can shift from repetitive selection work to genuinely non-standard designs.
Customers and dealers can receive faster feedback on feasibility and trade-offs.

Limitations and risks

A calculation model may be valid only within a defined operating envelope.
Automated results may be wrong when inputs are incomplete or product data is outdated.
Detailed simulation can introduce long processing times and specialist software dependencies.
CAD automation can fail when templates, geometry or naming conventions are not maintained.
Complex rules may become difficult to test and explain if ownership is unclear.
Safety-critical or regulated products may require formal engineering sign-off.
A CPQ result does not automatically replace design verification, certification or professional engineering judgment.

The system should distinguish between an automatically validated configuration, a configuration requiring review and a configuration that is outside the supported product model. A warning should explain the reason and the next action rather than merely displaying a generic error.

Implementation approach

1. Define the decision to automate

Start with a specific engineering decision, such as motor selection, nozzle sizing, enclosure dimensioning or load validation. Avoid attempting to automate an entire engineering process before the inputs, outputs and acceptance criteria are understood.

2. Document the existing method

Capture spreadsheets, selection charts, CAD templates, manual calculations and approval practices. Identify hidden assumptions and exceptions. A formula that exists only in an experienced engineer’s personal worksheet is not yet a governed product rule.

3. Separate inputs, rules and outputs

Define which values are customer requirements, which are derived values, which are constraints and which are commercial decisions. This separation makes testing and future maintenance easier.

4. Choose the calculation location

The calculation may run inside the CPQ rules engine, in a dedicated calculation service, in CAD automation software or in an external simulation platform. Selection should consider performance, licensing, security, maintainability, auditability and integration requirements.

5. Build test cases

Test normal configurations, boundary values, invalid combinations, missing data, unit conversions, changed product revisions and failure responses. Include known engineering examples and independently verified results.

6. Establish review and release governance

Assign ownership for formulas, material data, component ratings, CAD templates and product rules. Changes should be versioned, reviewed and tested before being released to sales or dealers.

7. Pilot a bounded product family

A pump family, standard enclosure range or modular conveyor is often easier to pilot than a complete product portfolio. Measure calculation accuracy, engineering review time, quote rework, failed configurations and maintenance effort.

Implementation planning should also cover migration, integrations, deployment, user adoption and long-term governance. The manufacturing CPQ implementation guide provides a broader framework.

Integration considerations

Calculation-driven CPQ commonly exchanges data with several enterprise systems. A customer relationship management (CRM) system may provide the opportunity and account context. CPQ manages configuration and quote logic. PLM or PDM may provide controlled engineering definitions. CAD generates geometry. ERP receives order, item, pricing or BOM data. A product information management (PIM) system may provide descriptions and commercial content. MES may consume production data later in the process.

Integration design should specify the direction, timing, ownership and format of each data exchange. It should also define what happens when a calculation service is unavailable, a CAD job fails or an ERP item does not yet exist. APIs, event messages, files and middleware can all be valid approaches depending on the environment.

How to evaluate a CPQ configurator for engineering calculations

When evaluating software, ask vendors to demonstrate a realistic product scenario rather than a generic option-selection screen. The demonstration should include numeric inputs, dependencies, calculations, a boundary condition, a generated BOM and a handoff to an engineering or ERP system if those capabilities are required.

Can the platform model formulas, constraints and calculated attributes?
Can users see why a configuration is invalid or requires review?
Can calculations be versioned and tested independently?
Can the platform call external calculation or simulation services?
Can calculated values drive component selection and BOM logic?
Can CAD parameters, drawings or 3D outputs be generated or exchanged?
How are engineering approvals and exceptions represented?
Can the system preserve the exact inputs, rules and revisions used for a quote?
What happens when a calculation, integration or CAD generation job fails?
Which capabilities are native, and which require custom development or partner software?

Do not assume that a platform described as a CPQ configurator includes engineering simulation, CAD automation or manufacturing BOM generation. Verify each capability against the required product family and operating process. The manufacturing CPQ comparison and selection guidance can help structure this evaluation.

Semantic map

The article connects the following entities and concepts:

Manufacturing CPQ connects customer requirements with product configuration, engineering validation and quoting.
Configuration rules prevent invalid option combinations.
Engineering calculations transform requirements into technical values and component selections.
Simulation evaluates modeled product behavior under defined conditions.
Calculated values can drive CAD parameters and product-specific drawings.
Configured products can generate configurable BOMs and order structures.
Engineering BOMs describe design structure, while manufacturing BOMs support production structure.
CPQ exchanges configuration and commercial data with ERP, CRM, PLM, PDM, CAD, PIM and MES systems.
CTO uses predefined product choices, while ETO includes order-specific engineering.
Engineering governance controls formulas, product data, revisions, testing and approvals.

Frequently asked questions

What is simulation in a manufacturing CPQ system?

Simulation in manufacturing CPQ evaluates how a proposed configurable product may behave under modeled operating conditions. It can cover structural, thermal, fluid, motion or other engineering behavior and may use an external specialist application.

Are engineering calculations the same as configuration rules?

No. Rules determine whether selections are allowed, while engineering calculations derive technical values or selections from inputs. A calculation can support a rule, but the two capabilities should be modeled and tested separately.

Can a CPQ system calculate motor size?

It can when the product model contains suitable inputs, formulas, performance data and validation limits. For example, load, speed, torque, duty cycle and efficiency may be used to recommend a motor, subject to engineering review where necessary.

Can calculations generate a BOM?

Yes, in systems that support calculated product structures or BOM logic. A calculated result may select components, quantities or subassemblies, but the resulting BOM should be reconciled with the organization’s engineering and manufacturing systems.

Does every manufacturing CPQ platform include simulation?

No. Some platforms provide rules and formulas only. Others integrate with CAD automation, calculation services or simulation software. The required capability must be verified for the specific product and engineering use case.

What is the difference between a formula and a simulation?

A formula usually calculates a result directly from defined variables. A simulation models behavior over conditions or time and may involve more complex numerical methods, larger data sets and longer execution times.

Can sales representatives use engineering calculations?

Yes, if the user interface exposes only the necessary inputs and the product model controls technical boundaries. Complex or safety-sensitive results may still require a sales engineer or engineering approval.

How does CAD automation use calculated values?

CAD automation can map calculated dimensions, selected options and component choices into parametric templates. It may then generate a 3D model, 2D drawing, installation layout or other product-specific output.

What happens when a configuration is outside the calculation model?

The system should identify the condition clearly and route it to engineering review, reject it as unsupported or initiate an ETO workflow. It should not silently produce a standard quote for an unvalidated design.

How do calculations affect pricing?

Calculations can determine required materials, components, capacity or processing, which then influence cost and price. The calculation engine determines technical requirements; the pricing engine applies commercial rates, margins, discounts and approvals.

Can an engineering calculation be stored with the quote?

A well-designed system should preserve inputs, outputs, assumptions, rule or formula versions and review status with the configuration or quote. This supports auditability and later reproduction of the result.

What data is needed for a reliable engineering calculation?

Typical data includes requirements, units, material properties, component ratings, performance curves, environmental conditions, safety factors and defined operating limits. The data must also be versioned and maintained.

When should a simulation run synchronously?

Synchronous execution is suitable when the calculation is fast and stable enough to provide immediate feedback. More demanding analyses are usually better handled asynchronously or after an initial configuration.

How does CPQ support engineer-to-order products?

CPQ can capture requirements, perform preliminary calculations, generate a preliminary structure and create an engineering request. Engineering then resolves non-standard design work before final approval and production release.

What is the role of PLM in calculation-driven CPQ?

Product lifecycle management (PLM) may provide controlled product definitions, revisions, materials, approved components and engineering change information. CPQ can use that data while managing the customer-specific configuration and quote workflow.

How should calculation rules be tested?

Testing should include normal cases, boundary values, invalid inputs, missing data, unit conversions, product revisions, integration failures and independently verified engineering examples. Results should be reviewed by qualified subject-matter experts.

Can a CPQ calculation replace engineering approval?

Not automatically. It can reduce repetitive work and validate standard configurations, but regulated, safety-critical, novel or out-of-range designs may still require formal engineering verification and approval.

What should buyers ask CPQ vendors about engineering calculations?

Ask whether formulas, constraints, external services, simulation jobs, CAD parameters, BOM logic, versioning, audit trails and approvals are supported natively or through customization and integrations. Request a demonstration using representative manufacturing data.

September 15, 2026

Engineering Calculations Inside a Product Configurator

Engineering calculations inside a manufacturing product configurator turn customer requirements into technically valid product definitions. Instead of allowing a salesperson to select isolated options, the configurator can calculate dimensions, capacities, loads, material quantities, motor sizes, electrical ratings or other engineering values and use the results to select compatible components.

In manufacturing CPQ, CPQ means configure, price, quote. A calculation-enabled CPQ system can connect product configuration rules with engineering formulas, pricing, bills of material (BOMs), computer-aided design (CAD) outputs and downstream enterprise systems. For example, a pump configurator might use flow rate, pressure, fluid properties and operating temperature to recommend a pump size, impeller diameter, motor rating and material combination. The result can then drive a quote, a configurable BOM, a CAD model or an engineering review.

Not every CPQ platform supports engineering calculations. Some systems provide only guided selling, option rules and pricing. Others include a rules engine, calculation service, CAD automation or integration with external engineering applications. Buyers should therefore verify exactly where calculations run, which variables they support, how results are tested and whether the outputs are suitable for production.

What are engineering calculations in a product configurator?

Engineering calculations in a product configurator are formulas, algorithms and decision rules that derive technical product values from customer inputs, selected options, operating conditions and manufacturing constraints.

These calculations may produce:

required dimensions such as length, width, height, diameter or wall thickness;
performance values such as flow, pressure, capacity, speed, torque or heat transfer;
component selections such as motors, pumps, valves, drives, bearings or structural members;
material quantities, weights, surface areas and cutting lengths;
electrical values such as voltage, current, breaker size or cable requirements;
manufacturing parameters used in a BOM, routing, drawing or CAD model;
cost, price, margin or surcharge inputs derived from the technical result.

The calculation is part of a wider product model. The model defines features, options, parameters, dependencies, constraints, formulas, component relationships and outputs. A calculation should not be treated as an isolated spreadsheet copied into a sales tool. It should be governed as engineering logic with known inputs, units, assumptions, valid ranges, revision control and test cases.

See the guide to product configuration and configuration rules for the relationship between product models, options, dependencies and validation.

Why engineering calculations matter in manufacturing CPQ

Generic sales CPQ often focuses on selecting commercial options, applying discounts and generating a proposal. Manufacturing CPQ may need to establish whether a product can be built and what its technical definition should be before a quote is released.

Without embedded or connected calculations, the sales process commonly depends on manual engineering work. An application engineer may review a spreadsheet, resize a component, update a drawing, create a BOM and return a price. This can be appropriate for genuinely novel designs, but it creates delays and increases the risk of inconsistent assumptions for repeatable product families.

A calculation-enabled configurator can automate the repeatable portion of that work. It can reject impossible combinations, recommend a valid design envelope, identify when a standard component is insufficient and route exceptional cases to engineering. The objective is not to remove engineering judgment. It is to apply approved engineering knowledge consistently and reserve expert time for cases that actually require review.

Manufacturing problem	Role of a calculation-enabled configurator
Sales selects a motor that cannot meet the load	Calculates required torque or power and restricts motor choices to valid ranges
A frame is too small for the specified span	Calculates dimensions or structural requirements and identifies a compatible frame family
Material quantity changes with product dimensions	Calculates quantity, weight and cost drivers for the configured design
Each quote requires a new drawing	Passes calculated parameters to CAD automation where supported
Engineering receives incomplete order information	Transfers validated parameters, selections, BOM data and assumptions with the handoff

How calculations fit into the configurator architecture

A typical architecture separates the user interface, product model, rules engine, calculation logic, output generation and connected business systems. The exact design varies by platform, but the following flow is common:

Requirement capture: The user enters customer requirements such as capacity, dimensions, environment, voltage, material or duty cycle.
Configuration validation: Rules check required fields, incompatible options, ranges and dependencies.
Calculation: Formulas or engineering services derive technical values from the validated inputs.
Component selection: The system selects or filters compatible components, variants and product families.
Output generation: The configurator produces price, cost, BOM, specifications, drawings, CAD parameters or review data, depending on its capabilities.
System integration: Relevant data is sent to enterprise systems such as customer relationship management (CRM), enterprise resource planning (ERP), product lifecycle management (PLM), product data management (PDM) or manufacturing execution systems (MES).

The calculation layer may be embedded in the CPQ platform, implemented as a rules service, connected to an external engineering application or distributed across several systems. The important requirement is a clear source of truth. If a motor-selection formula exists separately in a spreadsheet, CAD macro and ERP customization, the organization must define which result controls the quote and order.

Inputs, formulas and outputs

Every calculation should document three basic elements:

Inputs: values entered by the user, inherited from the product model, retrieved from a component database or supplied by another system;
logic: formulas, lookup tables, constraints, standards, coefficients and exception conditions;
outputs: calculated values, selected components, warnings, errors, cost drivers, BOM attributes or engineering deliverables.

Units and conversions require particular care. A calculation involving pressure, flow, torque or temperature can produce a dangerous result if the system silently mixes units. The data model should store units explicitly, define accepted input units and convert values in a controlled calculation layer.

Examples of engineering calculations

Pump and fluid equipment configuration

A pump configurator may capture required flow rate, differential pressure, fluid temperature, viscosity, corrosion requirements and available electrical supply. It can use these values to calculate a duty point, estimate hydraulic power and filter pump families. Additional rules may select impeller size, motor rating, seal material, casing material and connection type.

The result is not necessarily a final engineering certification. A configurator may use approved selection curves or lookup tables, while a specialist engineer may still need to verify cavitation margin, transient conditions, applicable standards or unusual fluid behavior. The system should make this boundary visible.

Industrial machinery and conveyor sizing

For a conveyor or material-handling machine, inputs may include product weight, throughput, belt speed, incline, conveyor length and operating environment. Calculations can estimate drive power, belt tension, roller spacing, frame dimensions and motor requirements. The outputs can drive a component selection, a configurable BOM and parameters for a 3D model.

Rules may also identify conditions that require review. For example, a standard frame may be available up to a specified span, while a longer span triggers a reinforced frame, additional supports or an engineer-to-order workflow.

HVAC and thermal equipment

An HVAC configurator may calculate heating or cooling capacity from airflow, entering and leaving temperatures, ambient conditions and application requirements. It can use the result to select a coil, fan, heat exchanger, enclosure, motor and control package. Material and environmental inputs may affect corrosion protection, insulation and enclosure ratings.

These calculations must be based on approved engineering methods and clearly defined assumptions. A simple capacity estimate may support preliminary selection, while final equipment performance may require detailed simulation, certification or a specialist review.

Electrical equipment

For an electrical panel or power distribution assembly, the configurator may calculate current demand from selected loads, apply diversity factors, select protective devices and determine enclosure size. It may also validate voltage, phase, short-circuit rating, wiring space and thermal constraints.

Electrical calculations often involve standards, regional requirements and installation conditions. The configurator should identify the governing standard and revision where relevant, rather than presenting a calculated result without context.

Specialty vehicles and mobile equipment

A vehicle configurator may calculate payload, axle loading, center-of-gravity limits, battery capacity, range estimates or hydraulic requirements. A selected body, lift or attachment can change the permissible payload and structural requirements. The system may therefore need sequencing rules: calculate the base vehicle first, apply the attachment, recalculate the combined configuration and then validate the result.

Rules, constraints and calculations are different

These concepts work together but should not be treated as interchangeable.

Concept	Purpose	Example
Guided selling	Asks questions to recommend a product or option	Recommend a pump family based on application type
Rules-based configuration	Defines if-then relationships and allowed choices	If the enclosure is outdoor-rated, require a suitable coating
Constraint-based configuration	Finds or validates combinations that satisfy multiple constraints	Select a motor and gearbox that meet torque, speed and space limits
Engineering calculation	Derives a value from inputs and formulas	Calculate required shaft torque from load and radius
Pricing logic	Converts selections and calculated drivers into cost or price	Apply a material surcharge based on calculated weight

A mature product model may use all five. A guided question captures the application, configuration rules validate selections, calculations derive technical values, constraint logic identifies feasible components and pricing logic converts the result into a commercial offer.

From calculation to BOM, CAD and quote

Configurable BOM, EBOM and MBOM

A bill of material (BOM) lists the components required for a product. A configurable BOM contains conditional or variable items that depend on the selected configuration.

An engineering BOM (EBOM) represents the product from an engineering and design perspective. A manufacturing BOM (MBOM) represents how the product is assembled and produced, including manufacturing-specific structure, operations or consumables where applicable. A CPQ-generated BOM may be an intermediate or sales-order structure rather than a complete production MBOM.

For example, a calculated enclosure size may determine the enclosure part number, mounting plate, cable length and hardware quantity. The system should distinguish between a calculated attribute, a sellable item, a manufactured part and a reference value. Sending all of these as undifferentiated lines to an ERP can create planning and costing problems.

CAD and 3D outputs

Where CAD automation is supported, calculated dimensions and selected components can become parameters for a 2D drawing, 3D model or visualization. A configurator may pass values to parametric CAD, select pre-engineered models or invoke a design automation service.

The CAD output should have defined status and purpose. A lightweight 3D model for sales visualization is not the same as a manufacturing drawing with tolerances, material specifications and revision control. A generated model may also require engineering approval before release.

CAD automation is covered in the CAD and engineering automation guide.

Pricing and quoting

Technical results often affect commercial results. Calculated weight may affect material cost and freight. Motor size may determine a purchased component cost. A larger frame may trigger labor, tooling or manufacturing surcharges. However, engineering calculations and pricing calculations should remain conceptually separate.

The calculation layer should produce approved technical drivers, while the pricing engine applies commercial rules such as currency, quantity breaks, discounts, markups and approval thresholds. Separating these concerns makes it easier to change a price policy without changing a safety-critical engineering formula.

Sales-to-engineering data flow

The main value of calculation-enabled CPQ is often the quality of the handoff. A completed configuration should communicate more than a product name and total price.

A useful handoff can include:

the customer requirements and original input values;
the selected options and calculated parameters;
assumptions, units and applicable standards;
validation messages, warnings and unresolved exceptions;
the selected components and configurable BOM;
CAD references or generated files where approved;
cost and price inputs without exposing inappropriate commercial data;
revision, author, timestamp and product-model version.

This information may move through an opportunity in a CRM system, an order or item structure in an ERP system, a product record in a PLM or PDM system, or an API between applications. CRM manages customer and sales context; ERP manages transactions, inventory, planning and financial data; PLM manages product lifecycle information; PDM commonly manages engineering files and revisions; CAD creates design representations; MES manages execution on the shop floor. These systems are related but not interchangeable.

See CPQ integration patterns for guidance on connecting these systems.

When calculations should trigger review or ETO

Configure-to-order (CTO) uses predefined options and rules to produce a valid product. Engineer-to-order (ETO) requires engineering work to create or adapt the design. Make-to-order (MTO) means production starts in response to an order, while assemble-to-order (ATO) assembles stocked or predefined modules after the order.

A calculation-enabled configurator can support CTO and identify the boundary between standard and engineered work. Examples of review triggers include:

a calculated value outside the validated range;
a component combination not represented in the approved product model;
an unusual material, temperature or environmental condition;
a load, pressure, voltage or safety value requiring certification;
a dimension that cannot be manufactured using standard tooling;
a conflict between customer requirements and available capacity;
a need for a new CAD design or design revision.

In these cases, the system should create an explicit engineering task rather than silently accepting an unverified result. The workflow may continue as ETO, or the product team may add the new case to the standard model in a later release. See manufacturing workflows for CTO, ETO, MTO and ATO.

Implementation approach

1. Select repeatable calculation candidates

Start with calculations that are common, well understood and based on stable engineering methods. Do not begin with the most complex bespoke design problem. A good first candidate may be motor sizing, enclosure selection, material quantity or a standard frame calculation.

2. Define ownership and source data

Identify who owns formulas, lookup tables, component ratings, material properties and standards. Determine whether product data comes from PLM, PDM, ERP, a component database or the CPQ product model. Avoid copying uncontrolled spreadsheets into production logic.

3. Model inputs and units explicitly

Define required, optional and derived values. Record units, valid ranges, precision, default assumptions and allowable conversions. Decide how missing, uncertain or approximate customer inputs are represented.

4. Separate validation from recommendation

A recommendation may suggest a motor or product family. Validation must establish whether the resulting configuration is allowed. The user interface should distinguish a recommendation, a warning, a blocking error and an engineering-review condition.

5. Define output contracts

Document what the calculation returns and how each result is used. For example, a calculated shaft diameter may be a design attribute, a CAD parameter, a BOM selection criterion and a quote explanation. Each downstream consumer should receive a stable data structure and version.

6. Test with engineering reference cases

Test normal, boundary, invalid and exceptional cases. Compare results against approved calculations, engineering software or controlled reference examples. Test unit conversions, rounding, missing values, rule sequencing and changes to component data.

7. Govern revisions

A formula change can alter a quote, BOM, drawing or production result. Record effective dates, approvers, model versions and affected products. Decide whether existing quotes and orders retain their original calculation version.

The CPQ implementation guide provides broader guidance on requirements, testing, deployment, governance and maintenance.

Limitations and risks

Engineering calculations do not automatically make a configurator an engineering authority. Important limitations include:

Incomplete inputs: Customer requirements may be approximate or misunderstood.
Model boundaries: A formula may be valid only within a defined operating range.
Data quality: Incorrect component ratings, material properties or revisions produce incorrect results.
Standards and certification: A calculated selection may still require formal compliance verification.
Complex physical behavior: Simulation, finite element analysis or specialist analysis may be necessary for novel designs.
Integration failures: A stale or partial transfer to ERP, PLM, CAD or MES can break the handoff.
Maintenance burden: Product changes, supplier substitutions and manufacturing changes require model updates.
False confidence: A precise-looking number is not reliable if assumptions and uncertainty are hidden.

The configurator should expose assumptions and route cases outside its validated domain to qualified engineers. It should not present an automated estimate as a certified design unless the organization has established that approval process.

How to evaluate a CPQ configurator for engineering calculations

During vendor evaluation, ask practical questions rather than relying on a general claim that the platform supports engineering. Verify whether it can:

represent variables, formulas, lookup tables and conditional logic;
handle units, ranges, precision and rounding;
sequence calculations when one result becomes another input;
separate warnings, blocking errors and review conditions;
version formulas and product models;
expose calculations through an application programming interface (API);
generate or exchange configurable BOM data;
pass parameters to CAD or design automation tools;
retain calculation inputs and outputs with the quote or order;
support testing, audit trails, approvals and rollback;
integrate with ERP, PLM, PDM, CRM and other relevant systems;
support both standard CTO products and exceptions requiring ETO.

Require a demonstration using a representative product family, such as a pump, machine frame, electrical enclosure or configured vehicle. Ask the vendor to show the underlying model, not only the final screen. Confirm which capabilities are native, which require customization and which depend on third-party engineering or CAD software.

Semantic map

The article connects engineering calculations with product configuration, rules, CAD automation, BOM generation, pricing, enterprise integration and manufacturing workflows. The main relationships are:

Customer requirements feed configuration inputs.
Configuration rules prevent invalid combinations.
Engineering calculations derive technical values.
Calculated values influence component selection and BOM structure.
CAD automation can use calculated parameters to generate models and drawings.
Technical results provide controlled inputs to costing and pricing.
Validated configurations improve the sales-to-engineering handoff.
Out-of-range results trigger engineering review or ETO.
ERP, PLM, PDM, CRM, CAD and MES consume different parts of the configured product data.

Frequently asked questions

What are engineering calculations in CPQ?

They are formulas, lookup tables and algorithms that derive technical values or component selections from customer requirements and configuration inputs. In manufacturing CPQ, they can support sizing, validation, BOM generation, CAD parameters and pricing inputs.

Does every CPQ system support engineering calculations?

No. Some CPQ systems focus on guided selling, option rules, pricing and quoting. Calculation, CAD automation and engineering integration may require a specialized manufacturing platform, customization or an external engineering service.

What is an example of a product configurator calculation?

A pump configurator can calculate required hydraulic power from flow and pressure, then use that result to select a pump family, impeller, motor and material combination.

How are calculations different from configuration rules?

A rule validates or controls a relationship, such as requiring an outdoor-rated enclosure with a suitable coating. A calculation derives a value, such as enclosure size or motor power, from one or more inputs.

Can a configurator calculate motor size?

It can when the product model contains an approved motor-sizing method and the required inputs, such as load, speed, torque, duty cycle and operating conditions. The result may still require engineering review outside the validated range.

Can engineering calculations generate a BOM?

They can contribute to BOM generation by determining dimensions, quantities, variants and component selections. Whether the platform creates a production-ready BOM depends on its native capabilities and integration with ERP, PLM or manufacturing systems.

What is the difference between a configurable BOM and an EBOM?

A configurable BOM contains conditional items that vary with the selected product. An EBOM represents the engineering product structure. A CPQ output may support an EBOM but should not automatically be treated as a complete manufacturing BOM.

Can calculated values drive CAD automation?

Yes, where the CPQ and CAD architecture supports it. Calculated dimensions, selected components and parameters can be passed to parametric CAD or design automation tools to create product-specific models and drawings.

Are CPQ calculations suitable for safety-critical products?

They may support preliminary selection or controlled standard designs, but safety-critical use requires defined engineering ownership, validation, standards compliance, testing and approval. Automation should not bypass required professional review.

What happens when a calculation produces an invalid result?

The system should show a blocking error, warning or engineering-review condition according to the severity. It should not silently create a quote or order from an unverified design.

How should units be handled in a configurator?

Units should be explicit in the data model, with controlled input units and documented conversion rules. This is essential for pressure, flow, temperature, torque, dimensions, mass and electrical values.

Can calculations affect product pricing?

Yes. Calculated weight, material quantity, motor size, labor content or manufacturing complexity can provide inputs to costing and pricing. The technical calculation and commercial pricing logic should remain separately governed.

How do calculations support configure-to-order?

They help validate predefined product families and derive the correct standard components for a customer-specific configuration. Cases outside the approved design envelope should be routed to engineering-to-order.

What systems exchange data with a calculation-enabled CPQ platform?

Depending on the architecture, it may exchange data with CRM for sales context, ERP for orders and materials, PLM or PDM for product data, CAD for design outputs and MES for manufacturing execution. These systems have different responsibilities.

Should calculations be stored in spreadsheets?

Spreadsheets can support analysis and prototyping, but uncontrolled spreadsheet logic is risky as a production source of truth. Approved formulas should be governed, versioned, tested and exposed through the product model or a controlled calculation service.

How should engineering calculations be tested?

Use approved reference cases covering normal, boundary, invalid and exceptional conditions. Test units, rounding, rule sequencing, component revisions, missing inputs and integration outputs.

What should a vendor demonstration include?

Ask the vendor to configure a representative machine or equipment family, enter real engineering inputs, show calculations and validation, generate the relevant BOM or CAD output and demonstrate the engineering-review path.

September 14, 2026

Technical Validation During Product Configuration

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.

September 12, 2026

Dimensional Product Configuration for Made-to-Measure Products

Dimensional product configuration allows a manufacturing Configure, Price, Quote (CPQ) system to create a valid, priced and manufacturable product from customer-specific measurements. Instead of selecting only predefined options, the user enters dimensions such as length, width, height, diameter, capacity or opening size. The CPQ product model then applies engineering rules, calculates dependent values, selects components, determines price and may produce a bill of materials (BOM), CAD output or manufacturing handoff.

This capability is important for manufacturers selling made-to-measure equipment, enclosures, conveyors, tanks, doors, windows, ductwork, heat exchangers, platforms, cabinets, vehicle bodies and other products whose geometry changes with the order. It is more than a sales form. A manufacturing configurator must connect customer requirements with product engineering, costing, production data and downstream enterprise systems.

Dimensional configuration is usually implemented as part of a broader product configuration model. Depending on the product and software architecture, it may also use CAD and engineering automation, configurable BOM logic, pricing calculations and integration with ERP, PLM or PDM systems.

What is dimensional product configuration?

Dimensional product configuration is the rules-based generation of a product variant from variable physical measurements and related engineering parameters.

A dimensional configurator does not simply store a measurement on an order. It evaluates whether the measurement is allowed, calculates values that depend on it, identifies compatible components and creates downstream data for quoting or production. For example, a configurator for a belt conveyor may accept conveyor length, belt width, incline angle, material type and load. It can then calculate drive requirements, select frame sections, determine support spacing and generate a product-specific BOM.

The term made-to-measure normally describes products that vary within defined dimensional ranges. It does not necessarily mean that every order is a completely new engineering project. A well-designed product model defines the boundaries within which the product can be configured repeatedly and safely.

How dimensional configuration differs from ordinary option selection

Traditional option-based configuration selects from fixed choices such as motor type, paint finish or control voltage. Dimensional configuration introduces continuous or semi-continuous variables. A user may enter 2,450 millimetres rather than select a standard length of 2,000 or 3,000 millimetres.

Configuration type	Typical input	Manufacturing implication
Option selection	Motor family or material grade	Selects a predefined item or rule branch
Dimensional configuration	Length, diameter or opening size	May change geometry, quantities, calculations and fabrication
Constraint-based configuration	Several related dimensions and requirements	Checks relationships and rejects invalid combinations
Engineer-to-order configuration	Dimensions outside the standard model	May require engineering review or additional design work

These approaches often operate together. A configurable pump skid may combine dimensional inputs for frame length with discrete selections for pump model, material, motor voltage and instrumentation.

The product model behind dimensional configuration

The product model is the structured representation of what can be sold and how it must be built. For dimensional products, it should separate customer-facing inputs from internal engineering variables and manufacturing outputs.

Customer-facing parameters

These are the values a salesperson, dealer, engineer or customer enters. Examples include:

overall length, width and height;
inside or outside diameter;
clear opening, working area or usable volume;
load, flow rate, pressure or capacity;
operating temperature and environmental conditions;
mounting location, connection size and orientation;
material, finish, insulation or regulatory requirement.

Input definitions should include units, permitted ranges, precision, default values and whether the value is mandatory. A system should also identify whether a dimension is customer-specified, calculated, inherited from another value or controlled by a standard.

Calculated parameters

Calculated parameters convert requirements into engineering values. A tank configurator may calculate shell area, volume, material mass and reinforcement requirements. A duct configurator may calculate cross-sectional area, pressure loss assumptions and panel counts. A machine enclosure configurator may calculate sheet-metal blank sizes, door clearances and the number of mounting rails.

Rules and constraints

Rules describe what is permitted and what must happen when a value changes. A minimum and maximum rule might restrict a platform width to a defined range. A dependency rule might require additional supports when length exceeds a threshold. A compatibility rule might prevent a selected motor from being used with a particular voltage or frame size.

Rules should be expressed in a maintainable form rather than hidden in application code wherever possible. They need owners, test cases, version control and an explanation that an application engineer can understand.

Dimensional rules and engineering constraints

Dimensional rules commonly fall into several categories:

Rule category	Example	Purpose
Range rule	Tank diameter must be between 600 and 3,000 mm	Prevents unsupported sizes
Relationship rule	Door height must be less than enclosure height minus clearance	Maintains geometric feasibility
Increment rule	Cut length must be supplied in 5 mm increments	Matches material or machine capability
Conditional rule	Lengths above 4,000 mm require a centre support	Adds required components
Compatibility rule	A selected actuator is unavailable above a defined load	Prevents unsafe or unsuitable combinations
Calculation rule	Motor power is selected from load and speed	Automates engineering selection
Approval rule	Non-standard pressure or temperature requires engineering review	Separates standard configuration from ETO work

Some products require constraint solving rather than a simple sequence of if-then statements. For example, a heat exchanger may need to satisfy flow, pressure drop, temperature and material constraints simultaneously. The configurator may use a calculation service, selection algorithm or engineering application to find an appropriate design. Buyers should verify how a CPQ platform handles such logic instead of assuming that every rules engine supports advanced constraint solving.

Worked example: a made-to-measure industrial enclosure

Consider an enclosure manufacturer selling electrical cabinets in custom widths, heights and depths. The customer enters an external width of 1,200 mm, height of 1,800 mm and depth of 400 mm, then selects stainless steel, a sealed door, a cooling unit and a defined ingress-protection requirement.

The product model may perform the following sequence:

Validate that the dimensions are within the supported manufacturing range.
Calculate usable internal volume after wall thickness, door clearance and mounting space.
Check that the selected cooling unit fits the available surface and heat-load requirement.
Determine sheet-metal panels, doors, hinges, locks, mounting rails, seals and fasteners.
Apply material, finish, labour and purchased-component costs.
Generate a configured BOM and, where supported, send geometry parameters to CAD automation.
Produce a quote and flag the order for engineering approval if a rule is exceeded.

A simple option configurator might capture the same dimensions but still require an engineer to calculate panel sizes and create the BOM. A manufacturing CPQ solution adds value when the dimensional logic is connected to repeatable engineering and production outputs.

Relationship between dimensions, BOMs and CAD

A bill of materials is the structured list of components required to build a product. An engineering BOM (EBOM) describes the product from an engineering perspective, while a manufacturing BOM (MBOM) organizes parts and operations for production. A configurable BOM contains rules that determine which items, quantities or variants apply to a particular configuration.

Dimensions can affect all three representations. Increasing the length of a conveyor may add frame sections, idlers, guards, cable lengths and supports. Increasing the diameter of a vessel may change shell plates, nozzles, reinforcement rings and welding operations. The CPQ system may generate an EBOM directly, pass configuration data to a product lifecycle management (PLM) or product data management (PDM) system, or send order-specific data to an ERP system that creates production structures.

CAD automation is a separate capability. A CPQ system may pass dimensional parameters to a parametric CAD model, invoke a design automation service or generate a drawing package. Not every CPQ product provides this functionality. Where CAD output is required, the implementation must define model ownership, revision control, drawing approval, file formats and the point at which engineering releases the design.

Pricing and costing for dimensional products

Dimensional inputs frequently influence price through material quantity, cutting length, surface area, weight, fabrication time, purchased components and transport requirements. Pricing should therefore be distinguished from configuration. The configuration determines what the product is; the pricing model determines what it costs or what the customer is charged.

For a made-to-measure duct section, for example, price may depend on sheet area, gauge, insulation, number of seams, fittings and installation accessories. A tank may require separate calculations for material mass, welding hours, testing and surface treatment. A CPQ system can perform these calculations, but the source data and formulas must be governed. Cost rates, supplier prices, labour assumptions and commercial markups require different ownership from engineering constraints.

Where dimensional configuration fits in the manufacturing workflow

Dimensional configuration can support several operating models:

Configure-to-order (CTO): the customer selects within a validated product family and the system produces repeatable manufacturing data.
Make-to-order (MTO): the product is made after the order, often using standard or configurable components.
Engineer-to-order (ETO): the requirements require design work, calculations or approval beyond the standard product model.
Assemble-to-order (ATO): standard subassemblies are combined after the order, with dimensions possibly determining the selected combination.

A useful workflow distinguishes standard dimensional variation from genuine engineering exceptions. A dimension outside the supported range should not be forced through the configurator simply to complete a quote. It should create an engineering review, an ETO task or a controlled request for a new product-model version.

The resulting data may move from CPQ to customer relationship management (CRM), enterprise resource planning (ERP), PLM, PDM, manufacturing execution system (MES) or CAD systems. These systems are not interchangeable: CRM manages customer and opportunity information, ERP manages commercial and operational transactions, PLM and PDM manage product data and revisions, MES manages shop-floor execution, and CAD manages geometric design.

See the guide to configure-to-order, engineer-to-order and sales-to-engineering workflows and the overview of CPQ integrations.

Benefits of dimensional product configuration

Faster quoting: sales engineering can produce a technically bounded quote without manually rebuilding calculations for every inquiry.
Fewer configuration errors: invalid dimensions, incompatible components and missing dependencies can be blocked before order entry.
Reduced repetitive engineering: standard calculations and drawings can be reused for products within the approved model.
More consistent pricing: material, labour and component effects can be calculated from the same configuration data.
Better sales-to-production handoff: the order contains structured dimensions and selections rather than only free-text notes.
Improved product knowledge: rules make implicit engineering decisions visible and testable.

Limitations and risks

Dimensional CPQ does not remove the need for engineering judgment. It can only automate logic that has been defined, tested and maintained. Products with poorly documented design knowledge often expose the greatest implementation difficulty.

Rules can become difficult to maintain when one product model contains too many exceptions.
Engineering formulas may depend on assumptions that are not recorded in the CPQ model.
CAD, BOM and ERP integrations can create revision and synchronization problems.
Rounding, units and tolerances can produce different results between systems.
Commercial pricing may change faster than engineering rules, requiring separate governance.
Non-standard requests can be incorrectly presented as standard configurations.
Highly complex products may require specialist calculation or constraint software rather than only a CPQ rules engine.

Validation must cover boundary values, unit conversions, calculated dimensions, unavailable components, revision changes and combinations that should be rejected. Test data should include realistic product families rather than only simple examples.

Implementation approach

1. Define the standard configuration boundary

Document which dimensions, materials and options can be sold without engineering intervention. Identify the point at which a request becomes ETO or requires approval.

2. Inventory product knowledge

Collect drawings, spreadsheets, selection charts, calculation methods, BOM structures, price formulas and exception rules. Resolve conflicting sources before building the model.

3. Separate inputs, rules and outputs

Define customer inputs separately from calculated engineering values, commercial values and manufacturing outputs. This improves traceability and makes changes safer.

4. Establish units and precision

Specify the system of measurement, display precision, calculation precision, rounding policy and tolerances. A value displayed as 2,450 mm may be stored and calculated at a different precision.

5. Assign ownership

Product engineering should own technical constraints, manufacturing should validate production structures, commercial teams should own pricing policy and IT should govern integrations and environments.

6. Test the model

Test normal configurations, minimum and maximum dimensions, threshold transitions, incompatible selections, obsolete components and deliberately invalid combinations. Compare generated BOMs, drawings and prices with approved reference outputs.

7. Plan releases and change control

Product models need versioning. A rule change may affect open quotes, released orders, CAD files, BOMs and ERP item references. The implementation should define when an old configuration remains valid and how historical outputs are preserved.

The broader CPQ implementation guide covers requirements, testing, governance, deployment and maintenance in more detail.

How to evaluate a dimensional CPQ configurator

When evaluating software, manufacturers should ask practical questions rather than count generic features:

Can the system model continuous dimensions, ranges, increments, tolerances and units?
Can calculated values be reused across rules, pricing, BOMs and documents?
Can the model distinguish standard configurations from engineering-review cases?
Can rules be maintained by authorized product experts without uncontrolled code changes?
Can the system generate or exchange configurable BOM data?
Can it integrate with the required CAD, PLM, PDM, ERP and CRM systems?
How are revisions, approvals, test cases and historical configurations managed?
Can the architecture support dealer, internal sales, ecommerce or API-based channels?
What happens when a dimension changes after a quote, order or engineering release?

Some platforms focus mainly on guided selling and quote generation. Others include deeper product configuration, engineering calculations, BOM generation or CAD automation. These capabilities should be verified against documented product behavior and a representative manufacturer product model.

Semantic map

The following relationships summarize the main entities and data flows in dimensional product configuration:

CPQ configures made-to-measure products.
Dimensional inputs drive engineering calculations.
Configuration rules prevent invalid combinations.
Constraints define supported product boundaries.
Calculated parameters determine dependent dimensions.
Configured products generate configurable BOMs.
Dimensions influence material quantities and costs.
CAD automation generates product-specific drawings.
CPQ exchanges configuration data with ERP.
PLM manages product revisions and engineering definitions.
PDM controls product files and design records.
ETO handles requirements outside the standard model.
Rules governance maintains product-model integrity.
Manufacturing data connects sales configuration with production.

Conclusion

Dimensional product configuration is the foundation for quoting and producing many made-to-measure industrial products. Its purpose is not merely to capture customer measurements. A robust model validates dimensions, applies engineering relationships, selects compatible components, calculates price and cost, and transfers structured data to the systems that support design and production.

The strongest implementations begin with a clearly defined standard product boundary and maintainable product rules. They distinguish configuration from pricing, EBOM from MBOM, standard CTO work from ETO work, and CPQ from the ERP, PLM, PDM, CAD and MES systems around it. With those boundaries established, a dimensional configurator can reduce repetitive engineering while preserving the controls needed for safe and manufacturable products.

Frequently asked questions

What is dimensional product configuration?

It is the process of creating a valid product variant from customer-specific measurements and related engineering requirements. The system may calculate dependent values, select components, determine price and generate manufacturing data.

Is dimensional configuration the same as product configuration?

Dimensional configuration is a specialized form of product configuration. General product configuration may select options, while dimensional configuration also evaluates variable physical measurements and their engineering relationships.

What products benefit from dimensional configuration?

Common examples include conveyors, tanks, enclosures, ductwork, windows, doors, platforms, vehicle bodies, heat exchangers, cabinets and other products whose geometry or material usage changes by order.

Can a CPQ system accept arbitrary dimensions?

It can accept variable dimensions only within the limits represented by the product model. Unsupported sizes should trigger an error, approval or engineer-to-order process rather than being treated as automatically valid.

How do dimensional rules prevent manufacturing errors?

They enforce ranges, increments, clearances, compatibility relationships and required components before the configuration becomes an order. This prevents many errors that would otherwise appear during engineering or production.

What is the difference between a dimension and a calculated parameter?

A dimension may be entered by the user, such as enclosure width. A calculated parameter is derived from inputs, such as usable internal width, panel area or required support spacing.

Does dimensional CPQ require CAD automation?

No. CAD automation is optional and depends on the product and platform. A configurator can validate dimensions and generate pricing or BOM data without creating CAD files, although CAD automation may reduce repetitive design work.

Can dimensional configuration generate a BOM?

Some manufacturing CPQ systems can generate or contribute to a configurable BOM. Others pass structured configuration data to ERP, PLM or another engineering system that creates the BOM. This capability must be verified for the specific platform.

How do dimensions affect product pricing?

Dimensions can change material area, weight, cutting length, fabrication time, purchased components, packaging and transport. Pricing logic can use these values, but the commercial formulas must be governed separately from engineering rules.

What is the difference between EBOM and MBOM in dimensional configuration?

An EBOM represents the product from an engineering perspective. An MBOM organizes the materials and structures needed for manufacturing. A dimensional configuration may influence both, but they serve different downstream purposes.

When should a dimensional request become ETO?

A request should become engineer-to-order when it exceeds approved dimensional ranges, requires a new design, needs an unvalidated calculation or introduces a manufacturing method not covered by the standard product model.

How should units and rounding be handled?

The implementation should define calculation units, display units, precision, rounding and tolerance rules. These standards must be consistent across CPQ, CAD, BOM, ERP and manufacturing outputs.

Who owns dimensional configuration rules?

Technical constraints normally belong to product or application engineering. Manufacturing validates production implications, commercial teams own pricing policy and IT governs integrations, environments and access.

Can dealers use a dimensional configurator?

Yes, if the system supports the required channel and permissions. Dealers may receive a simplified interface while the manufacturer retains control of technical rules, approvals, pricing and engineering outputs.

How are dimensional product models tested?

Testing should include valid configurations, boundary dimensions, threshold changes, unit conversions, invalid combinations, obsolete parts, price changes and comparisons with approved BOM or CAD reference outputs.

How does dimensional CPQ integrate with ERP?

It may send the configured product, quantities, prices, customer information and order details to ERP. The exact integration depends on system ownership, item structures, revision rules and whether the CPQ or ERP creates the production BOM.

Can AI replace dimensional configuration rules?

AI may assist with recommendations, natural-language input or analysis, but validated engineering constraints still need explicit control. A manufacturer should not rely on probabilistic output to enforce safety, compatibility or production rules.

September 9, 2026