Tag: event-driven architecture

Configuration data synchronization is the controlled exchange of product, option, rule, engineering, pricing and order data between a manufacturing CPQ system and the other systems in the manufacturing technology stack. A well-designed strategy keeps the configurator aligned with engineering-approved products, commercial pricing and production requirements without making every system a copy of every other system.

In manufacturing, CPQ means Configure, Price, Quote software used to select valid product combinations, apply engineering and commercial rules, calculate prices or costs, generate quotes and, in some implementations, produce bills of material, drawings or manufacturing inputs. Synchronization is therefore more than copying sales fields between a CPQ application and a CRM system. It can affect product models, constraints, revisions, configurable bills of material, CAD parameters, customer-specific prices and order data.

The central principle is simple: each type of data should have a defined system of record, a controlled synchronization method and an explicit versioning policy. ERP, PLM, PDM, CRM, CAD, PIM and MES systems should exchange the data they need, but they should not all independently own the same product definition.

For background, see the CPQ integrations guide and the guide to product configuration and configuration rules.

What configuration data must be synchronized?

A manufacturing configurator usually works with several related data categories. Treating them as one undifferentiated product record is a common cause of integration errors.

Data category	Typical examples	Possible system of record	Why CPQ needs it
Product structure	Product families, models, modules, options and variants	PLM, PDM or ERP	Defines what can be offered and how products are organized
Configuration rules	Dependencies, exclusions, required options and compatibility constraints	CPQ, PLM or a governed rules repository	Prevents invalid combinations
Engineering parameters	Flow rate, pressure, dimensions, load, voltage, material and capacity	Engineering systems, PLM or CPQ calculation models	Supports technical validation and sizing
EBOM and MBOM data	Engineering BOM, manufacturing BOM, components, quantities and operations	PLM and ERP	Connects the configured product to design and production
Commercial data	Prices, discounts, currencies, contracts and price validity dates	ERP, CRM or CPQ	Calculates a commercially valid quote
CAD and visualization data	Part references, dimensions, templates, models and drawing parameters	CAD, PDM or PLM	Generates product-specific engineering outputs where supported
Customer and opportunity data	Account, contacts, opportunity, territory and sales channel	CRM	Associates the configuration and quote with a commercial transaction
Manufacturing and execution data	Released items, routings, work centers and production status	ERP or MES	Supports order fulfillment and production planning

The correct ownership varies by organization. A smaller manufacturer may maintain the product model and rules in CPQ, while a larger engineering organization may govern product structures and revisions in PLM and publish an approved subset to CPQ.

Why synchronization is difficult in manufacturing CPQ

Manufactured products change in several dimensions at once. Engineering may replace a motor, add a new material, retire a valve, change a dimensional limit or revise a drawing. Sales may need a new regional price list. ERP may require a new item number. A configuration that was valid last month may need to remain valid for existing quotes even after the current product model changes.

These changes create several synchronization challenges:

• Different data models: A PLM product structure, a CPQ option model and an ERP item master may represent the same product at different levels of detail.
• Different identifiers: Systems may use internal item numbers, option codes, CAD part numbers and external product names that must be mapped.
• Different lifecycles: Engineering data may move from draft to review to released, while CPQ data may have draft, published and retired states.
• Different timing requirements: A price update may need to appear quickly, while an engineering revision may require review, testing and scheduled publication.
• Different purposes: An engineering BOM, manufacturing BOM and quote representation are related but are not interchangeable.
• Historical obligations: The company may need to reproduce the exact configuration, price and rules used for an earlier quote or order.

These issues mean that integration should be designed around business events, ownership and lifecycle states rather than only around database fields.

Core configuration data synchronization strategies

1. Single system of record with published downstream data

In this strategy, one system owns a particular class of data and publishes approved information to other systems. For example, PLM may own engineering product structures, ERP may own released item numbers and base costs, CRM may own customer and opportunity data, and CPQ may own the runtime configuration experience and selected commercial rules.

Downstream systems receive a controlled copy or projection of the source data. CPQ might receive released product families, allowed options, component references and revision metadata from PLM. It does not modify the engineering master directly.

This approach reduces conflicting edits and makes accountability clear. Its limitation is that the published model may not contain every detail needed by CPQ. A translation or enrichment layer is often required to convert engineering structures into a model suitable for guided configuration, pricing and quoting.

2. Master data publication and replication

Here, selected product and commercial data is replicated into CPQ on a scheduled or near-real-time basis. The CPQ system stores a local representation for fast configuration and availability during sales operations.

Replication is useful when the configurator needs low-latency access to a large product model, price book or option catalog. It also limits the number of live calls made during a sales session. However, replicated data can become stale. The integration must record the source revision, effective date, import status and validation result for each published object.

A manufacturer should avoid copying entire ERP or PLM databases into CPQ. Publish only the fields and structures needed for configuration, pricing, quoting and downstream handoff.

3. API-driven synchronous lookup

In synchronous integration, CPQ calls another system while a user configures or quotes a product. Examples include checking available inventory, retrieving a customer-specific price, validating a credit condition or obtaining a current material cost.

This provides current information but introduces runtime dependency. If an ERP pricing service is unavailable, the configuration or quote may be delayed. API calls should therefore have timeouts, clear fallback behavior, monitoring and a policy for whether a quote can be saved without the response.

Synchronous lookup is usually appropriate for volatile data. It is less suitable for every rule evaluation or every component lookup, particularly when a configuration contains hundreds or thousands of elements.

4. Event-driven synchronization

In an event-driven design, a system publishes an event when a meaningful business change occurs. Examples include ProductRevisionReleased, PriceListPublished, ComponentRetired, ConfigurationApproved or SalesOrderCreated. An integration service or message broker routes the event to interested systems.

Events reduce unnecessary polling and can provide faster propagation of important changes. They also require operational discipline. Messages may be delayed, duplicated or delivered out of order. Consumers should be idempotent, meaning that processing the same event more than once does not create duplicate or inconsistent records.

Events should carry stable identifiers, source revision, event timestamp, effective date and enough information for the receiving process to decide whether it can safely apply the change. A message that only says “product changed” is usually insufficient for controlled manufacturing integration.

5. Batch and scheduled synchronization

Batch integration exports and imports data at defined intervals, such as nightly price updates, weekly product publications or scheduled BOM transfers. It remains useful where source systems have limited APIs, where changes require review, or where business operations prefer a controlled release window.

Batch processes should not be treated as informal file drops. They need file schemas, validation, rejection handling, reconciliation reports, checksums or record counts, and an audit trail showing which release was imported. A failed batch should not silently leave CPQ with a partially updated product model.

6. Hybrid synchronization

Most manufacturing implementations use a hybrid approach. Stable product and rule data may be published from PLM to CPQ after approval. Customer and opportunity data may flow from CRM through APIs. Current customer pricing may be retrieved from ERP at quote time. Completed configurations may be sent to ERP and PLM asynchronously, with an acknowledgement returned to CPQ.

Hybrid architecture is usually more practical than forcing every data category into one integration pattern.

Define data ownership before designing interfaces

Data ownership answers who is allowed to create, change, approve and retire a record. It is different from technical storage. A CPQ database may store a copy of an ERP item, but that does not mean CPQ owns the item.

Data object	Questions to resolve
Product family and option	Who defines the option, its description, eligibility and lifecycle?
Configuration rule	Is the rule an engineering constraint, a sales recommendation or a commercial policy?
Engineering calculation	Which approved formula, characteristic table or sizing method is authoritative?
Item number	Which system creates and retires the item identifier?
EBOM	Which engineering system controls design structure and revision?
MBOM	Which manufacturing system controls production structure and operations?
Price	Who owns list price, cost, discount authority and effective dates?
Configuration snapshot	How is the exact quoted and ordered state preserved?

A responsibility matrix should identify the owner, contributors, approvers, consumers and synchronization method for each object. Without this, teams often create manual overrides in CPQ to compensate for missing source data, creating a second unofficial product master.

Synchronizing product models and configuration rules

A product model represents the choices, parameters and structure that a customer or salesperson can configure. It may include product families, features, options, quantities, dimensions, materials and dependencies. The model is not necessarily identical to an engineering BOM.

Rules should be classified because different rules have different owners and consequences:

• Validation rules reject technically invalid combinations, such as a motor that cannot support the selected pump duty.
• Dependency rules require one option when another is selected, such as requiring a control panel for a particular automation package.
• Exclusion rules prevent incompatible choices, such as a coating unavailable for a selected material.
• Calculation rules derive dimensions, capacity, weight, power or price from selected values.
• Recommendation rules suggest an option without making it mandatory.
• Commercial rules apply discounts, surcharges, regional availability or approval thresholds.

Rules-based configuration uses explicit conditions and actions. Constraint-based configuration evaluates a set of allowed relationships and constraints, which can be more suitable for highly variable engineered products. Guided selling asks questions to lead a user toward an appropriate product or option, but it does not by itself guarantee complete engineering validity.

When rules are synchronized from PLM or another engineering source, the receiving CPQ model may need transformation. A PLM structure can contain internal design parts that should never appear as selectable sales options. Conversely, CPQ may require customer-facing groupings and explanatory text that do not exist in PLM.

Synchronizing EBOM, MBOM and configurable BOM data

A bill of material, or BOM, lists the components that make up a product. An EBOM is an engineering BOM organized for design definition. An MBOM is a manufacturing BOM organized for production, assembly and process execution. A configurable BOM is a structure that resolves or expands based on selected options and parameters.

These structures should be related through explicit mappings, not assumed to be identical. A pump configuration may select a stainless-steel wetted part, a specific motor and a seal package. Engineering may manage those components in an EBOM, while manufacturing groups them into work-center assemblies in an MBOM. CPQ may generate a quote-level structure containing sellable modules, configuration attributes and references to released items.

Synchronization should preserve:

• source system and source revision;
• component identifiers and alternate identifiers;
• quantity and unit of measure;
• effectivity dates or serial ranges;
• option conditions and applicability;
• engineering versus manufacturing classification;
• make, buy, phantom and reference-only status;
• substitution and approved-alternative rules.

For more detail, see the guide to BOM generation, pricing and quote automation.

Pricing, costing and quote synchronization

Product validity and price validity are separate concerns. A product can be technically valid while its price is expired. A new engineering revision can also require a new cost, even if the customer-facing option name remains unchanged.

Price synchronization should define whether CPQ receives list prices, standard costs, customer-specific prices, discount matrices or only references to a pricing service. It should also define currency, unit of measure, quantity breaks, regional applicability, contract dates and rounding rules.

Cost data may be more restricted than sales price data. A manufacturer may allow CPQ to use a cost for margin calculation without exposing that cost to sales users or customers. Access control and field-level security are therefore part of the synchronization design.

A quote should store a snapshot of the price inputs and rules used at the time of calculation. Recalculating an old quote against today’s price list can create audit and customer-service problems.

CAD and engineering synchronization

CAD means computer-aided design. In an integrated manufacturing CPQ process, selected configuration parameters may be passed to CAD or engineering automation tools to generate a model, drawing, calculated dimension or product-specific document. Not every CPQ platform supports this capability.

Where CAD automation exists, synchronization should distinguish between:

• customer-facing visualization data;
• engineering parameters and design inputs;
• CAD templates and part references;
• generated geometry and drawings;
• approved design outputs and temporary previews.

For example, a configured conveyor may pass belt length, frame width, drive position and guarding selection to a parametric CAD process. The returned drawing should carry the configuration identifier and revision so that it can be traced to the quote or order. A preview image is not equivalent to an approved manufacturing drawing.

See CAD and engineering automation in CPQ for the relationship between product configuration, calculations, visualization and design outputs.

Integration patterns across ERP, PLM, CRM, PDM, PIM and MES

Enterprise systems have different responsibilities:

• CRM, or customer relationship management, manages accounts, contacts, opportunities and sales activities.
• ERP, or enterprise resource planning, commonly manages items, inventory, purchasing, costs, orders, finance and production-related transactions.
• PLM, or product lifecycle management, manages product definitions, revisions, change processes and engineering lifecycles.
• PDM, or product data management, manages engineering files, CAD documents, versions and access control.
• PIM, or product information management, manages descriptive and channel-oriented product content.
• MES, or manufacturing execution system, manages or records shop-floor execution and production status.
• CAD, or computer-aided design, creates engineering models and drawings.

CPQ sits between commercial selection and technical fulfillment. It may receive customer context from CRM, product and revision data from PLM or PDM, price and item data from ERP, content from PIM, and design parameters from CAD-related services. It may then return a quote to CRM, a released configuration to ERP, an engineering request to PLM and production-relevant information to downstream systems.

These integrations should use stable cross-system identifiers. Names and descriptions are useful for display but are unsafe as primary keys because they change, may be translated and may not be unique.

Versioning, effectivity and configuration snapshots

Versioning is essential when configurations must remain reproducible. At minimum, a configuration snapshot should identify the product model revision, rule-set revision, selected options, calculated values, price-list revision, currency, user, timestamp and approval status.

Manufacturers should also define effectivity. A change may be effective from a calendar date, production order date, serial number, plant, market or customer contract. A product revision released in PLM should not automatically invalidate every open quote unless that is the agreed business policy.

Useful lifecycle states include draft, under review, approved, published, superseded and retired. Synchronization should move data only through permitted transitions. A retired component may remain valid for historical orders but should be blocked for new configurations.

Conflict handling and data quality controls

Conflicts occur when two systems change related data before synchronization completes. Examples include an engineer retiring an option while a pricing administrator updates its price, or an ERP item changing status while CPQ still references the old item number.

Effective controls include:

1. Define one authoritative owner for each field or object.
2. Use revision and effective-date checks before applying updates.
3. Reject incomplete or ambiguous records instead of importing them silently.
4. Maintain an exception queue with an accountable owner.
5. Log the source, target, timestamp, payload version and result of every transfer.
6. Use reconciliation reports to compare counts, identifiers, revisions and statuses.
7. Support replay of failed events or batches after the underlying problem is corrected.
8. Use idempotency keys to prevent duplicate order, quote or BOM creation.

Data quality tests should cover missing identifiers, invalid units, orphaned options, duplicate codes, circular dependencies, retired components, missing prices and BOM quantities that do not resolve correctly.

Security and governance considerations

Configuration synchronization can expose confidential product designs, customer information, costs and pricing authority. Integration accounts should use least-privilege access. A CPQ service that only reads released PLM data should not have permission to alter engineering revisions.

Governance should define who approves new rules, who can publish a model, how emergency changes are handled and how changes are communicated to sales, engineering and production. Rule changes should be tested with representative configurations before publication.

For a broader implementation approach, see the CPQ implementation and governance guide.

Testing a synchronization architecture

Testing should include both technical transport and manufacturing meaning. A message can be delivered successfully while still producing an incorrect product model.

Test level	Example
Schema validation	Confirm required identifiers, data types, units and revision fields
Mapping test	Verify that an ERP item and PLM component map to the intended CPQ object
Rule test	Confirm that incompatible motor, voltage and pump selections are rejected
Lifecycle test	Verify behavior when an option changes from released to retired
Calculation test	Compare capacity, dimensions, cost and price with approved reference results
End-to-end test	Configure, quote, approve and transfer an order into ERP or engineering
Failure test	Simulate unavailable APIs, duplicate events and partial batch failures
Historical test	Reproduce an earlier quote using its stored model and price revisions

Regression testing is particularly important for large rulesets. A change to one dependency can affect many product families, regions or dealer workflows.

Implementation roadmap

1. Inventory data objects: List product, rule, engineering, BOM, price, customer, order and document data that crosses system boundaries.
2. Assign ownership: Document the source of truth, approved editors and consumers for every important object.
3. Define canonical identifiers: Establish keys for products, options, components, revisions, configurations and quotes.
4. Choose synchronization frequency: Separate real-time requirements from data that can be published in controlled batches.
5. Design the target model: Decide which source structures are copied, transformed, calculated or referenced by API.
6. Build validation and reconciliation: Detect incomplete data before it reaches the live configurator.
7. Implement version and effectivity handling: Preserve historical configurations and manage future-dated changes.
8. Test representative products: Include standard configurable products, highly engineered products, revisions, substitutions and exceptional cases.
9. Release in stages: Start with a limited product family or sales channel and measure errors, latency and manual rework.
10. Establish operating ownership: Assign responsibility for monitoring, failed messages, rule maintenance and model releases.

Common mistakes to avoid

• Allowing every system to edit the same product and rule data.
• Synchronizing names instead of stable identifiers.
• Treating an EBOM, MBOM and quote BOM as interchangeable.
• Using live API calls for data that should be locally validated and versioned.
• Copying all ERP or PLM data into CPQ without a clear purpose.
• Publishing engineering changes without testing sales and manufacturing consequences.
• Failing to preserve the exact rule and price revisions used for a quote.
• Assuming successful message delivery means successful business processing.
• Embedding undocumented manual overrides in the configurator.
• Ignoring units of measure, currencies, time zones and effective dates.

How to evaluate a CPQ synchronization approach

When evaluating a CPQ configurator, ask vendors and implementation partners specific manufacturing questions rather than accepting a general claim about integrations.

• Which systems can be sources of product, rule, price and BOM data?
• Can the platform preserve model, rule, price and configuration revisions?
• Does it support APIs, webhooks, events, scheduled imports and export acknowledgements?
• How are failed messages, duplicate events and partial imports handled?
• Can the platform distinguish engineering, manufacturing and quote structures?
• How are units, currencies, effectivity dates and alternate components represented?
• Can configuration snapshots be reproduced after a product model changes?
• Which capabilities are standard, which require custom development and which require a separate integration platform?
• Can rules and product data be tested before publication?
• How are permissions, approvals, audit logs and emergency changes managed?

These questions help distinguish a manufacturing-capable architecture from a generic sales quoting connection.

Semantic map

The article connects the following entities and relationships:

• CPQ connects commercial configuration with engineering and production systems.
• PLM owns or governs released product structures and revisions in many manufacturing architectures.
• ERP owns or manages items, costs, orders and production-related transactions in many organizations.
• CRM supplies customer, account and opportunity context to CPQ.
• Configuration rules prevent invalid product combinations.
• Product model revisions control which options and constraints are published.
• Configured products can generate quote BOMs or downstream manufacturing structures.
• EBOM describes an engineering view of a product.
• MBOM describes a manufacturing view of a product.
• CAD automation can generate product-specific drawings when the CPQ and engineering architecture supports it.
• Events communicate approved changes between systems.
• Configuration snapshots preserve historical quote and order decisions.
• APIs provide synchronous access to selected current data.
• Batch integration publishes controlled data sets on a schedule.
• Data ownership determines which system may create or change a record.

Frequently asked questions

What is configuration data synchronization in CPQ?

It is the controlled exchange of product, option, rule, engineering, pricing, BOM and transaction data between CPQ and systems such as ERP, PLM, CRM, CAD and MES.

Why is synchronization important for manufacturing CPQ?

It keeps the configurator aligned with approved products, current prices and production requirements while reducing invalid configurations, manual re-entry and engineering rework.

Which system should own product configuration data?

There is no universal answer. PLM or PDM may own engineering structures, CPQ may own the sales configuration model, and ERP may own released items. Ownership should be assigned by data object.

Should CPQ be the master product database?

Usually not for every product object. CPQ may own the runtime configuration model, but engineering revisions, item masters and manufacturing structures often belong in PLM or ERP.

How does CPQ synchronize with ERP?

Common patterns include APIs, events and scheduled imports or exports for items, prices, costs, orders, inventory-related data and configured product information.

How does CPQ synchronize with PLM?

PLM may publish approved products, options, revisions, characteristics and engineering structures to CPQ. CPQ may return configuration decisions or engineering requests, depending on the architecture.

What is the difference between real-time and batch synchronization?

Real-time synchronization exchanges data during a transaction or shortly after a change. Batch synchronization transfers controlled data sets on a schedule. Many manufacturers use both.

When should CPQ use an API lookup?

API lookup is useful for volatile information such as customer-specific pricing, availability or credit status. It should include timeout, fallback and error-handling policies.

When are events better than direct API calls?

Events are useful when an approved change should notify multiple systems without tightly coupling the publisher to every consumer, such as a released product revision or published price list.

What is an EBOM?

An engineering BOM is a bill of material organized to represent the product from an engineering and design perspective. It is not automatically the same as a manufacturing BOM or quote BOM.

What is an MBOM?

A manufacturing BOM is a bill of material organized for production, assembly and manufacturing processes. It may regroup or transform engineering components for shop-floor execution.

Can a CPQ system generate a BOM?

Some manufacturing CPQ platforms can generate configurable or downstream BOMs, but this capability is not universal. Buyers should verify supported BOM types, revisions, quantities and ERP or PLM handoff.

How should configuration rules be synchronized?

Rules should be published with identifiers, dependencies, version, lifecycle state, effective date and ownership. They should be validated and regression-tested before becoming active.

How are pricing and configuration synchronized?

CPQ may receive price lists and costs from ERP, CRM or a pricing service, or calculate them locally. The quote should preserve the price-list revision and inputs used.

How can a manufacturer preserve an old quote after a product change?

Store a configuration snapshot containing selected options, calculated values, rule revision, product revision, price revision, currency and timestamp.

What happens if two systems change the same product?

The integration should apply ownership and revision rules, reject conflicting updates when necessary, and send exceptions to an accountable data steward or product owner.

How does CAD automation affect synchronization?

Selected CPQ parameters may be sent to CAD or engineering automation to create models or drawings where supported. Generated outputs should carry configuration and revision references.

What identifiers should integrations use?

Use stable product, option, component, revision, configuration and transaction identifiers. Names and descriptions should be treated as display fields rather than reliable keys.

How should synchronization failures be monitored?

Monitor message delivery, validation errors, processing status, latency, rejected records, retry counts and reconciliation differences. Provide replay and exception-management processes.

Is synchronization different for CTO and ETO products?

Yes. Configure-to-order products often use stable rules and released structures, while engineer-to-order products may require engineering tasks, provisional data, approvals and later CAD or BOM updates.

What is the biggest synchronization mistake?

The most damaging mistake is allowing multiple systems to independently own the same product or rule data without clear authority, revision control and reconciliation.