How to Connect a Digital Product Passport to ERP, PIM and PLM Without Creating a Second Product Master

The dangerous DPP integration is the one that quietly becomes another product master. It starts innocently: copy a few fields from ERP, enrich them in the passport, add a workflow, then allow another system to update the copy. Before long, nobody can explain which value is authoritative or why two systems disagree. The safer pattern is a controlled projection. Source systems keep authority, changes move through explicit integration contracts and the Digital Product Passport publishes a governed view with provenance, validation and reconciliation state.

The anti-pattern: a second product master

A DPP needs product information from several systems because enterprise product data is rarely owned in one place. An ERP may hold operational product master data. A PIM may hold channel-ready product content. A PLM may hold engineering or specification data. Separate event systems can hold what happened to a product over time.

That does not mean the DPP should absorb all of those systems into one new database.

GS1's EPCIS 2.0 standard explicitly distinguishes event data from master data: it standardises capture and query of visibility events while leaving the means by which master data enters the system outside that scope. GS1 resolver architecture similarly allows one identified entity to resolve to multiple resources without requiring those resources to be collected into a single store. (GS1 EPCIS 2.0, GS1-Conformant Resolver 1.2.1)

The practical implication is important. A DPP can present a coherent product view while the underlying facts remain distributed.

A second-master anti-pattern usually appears when one or more of these things happen:

• copied source fields become editable without a clear authority rule;
• each inbound message overwrites the prior value regardless of source, version or effective time;
• event history is flattened into current-state master data;
• reconciliation exceptions disappear into manual fixes with no audit trail;
• downstream consumers start treating the passport copy as authoritative simply because it is easy to access.

If fact ownership is still unresolved, stop here and settle which system should own each product fact before designing the runtime integration.

The five-plane integration architecture

We use a five-plane model to keep the integration problem understandable:

Identity → Authority → Event/State → Publication/Resolution → Control

This is an ActivateDigital synthesis of the patterns in the accepted standards, platform documentation and reference architectures. It is not an industry-mandated architecture.

The model forces two separate questions that are often mixed together: what is true? and how did the change get here? The first is an authority problem. The second is an integration problem.

For cross-system identity, use the sibling guide on mapping product IDs across GTIN, SKU, ERP, PIM and DPP systems. This page starts after that mapping problem has been made explicit.

What should remain authoritative upstream

The exact source of truth for a field is enterprise-specific, so this article does not assign ownership by system type. The rule is simpler: if a fact is authoritative upstream, the DPP should retain its provenance rather than create a competing authority.

SAP's current S/4HANA Cloud product APIs illustrate the point. Product master entities can be accessed through CRUD and batch APIs covering data such as descriptions, GTINs, plant, procurement, sales and warehouse information. The existence of those APIs makes propagation possible. It does not make the DPP the owner of the underlying product master. (SAP Product Master APIs)

Likewise, a lifecycle event does not automatically become a replacement master fact. GS1 US's Culinary Collaborations case shows GTIN/product master data being used alongside EPCIS traceability events from processors and logistics partners. The case demonstrates coexistence of master and event data, not a requirement to store both in one master. (GS1 US Culinary Collaborations case study)

If you need the event/master distinction in more depth, the canonical handoff is what EPCIS events add to product master data.

What the DPP layer may legitimately persist

Avoiding a second master does not mean the DPP must be stateless.

A useful publication layer normally needs enough state to explain what it published, where it came from and whether it is still current. Depending on the architecture, that can include:

• identifier crosswalks and source mappings;
• a publication projection optimised for the DPP response;
• source version or change tokens;
• last successful synchronisation checkpoints;
• validation state;
• unresolved conflicts and review queues;
• publication status by field or record;
• audit history and provenance;
• resolver targets and access-control metadata.

This is the difference between persisting control state and claiming master-data authority.

Distributed architectures can reduce unnecessary copying. Microsoft Dataverse virtual tables, for example, can expose externally stored data without replicating it, although they carry feature and latency constraints. Eclipse Tractus-X's EcoPass reference architecture similarly separates discovery through a Digital Twin Registry, data in submodel servers and controlled access through connectors. (Microsoft virtual tables, Eclipse Tractus-X EcoPass operation view)

Distributed does not mean governance-free. The publication layer still needs authority, mapping, validation and failure rules.

Batch, API, webhook, CDC or event stream?

There is no universal best transport for DPP integration. The right choice depends on how quickly the change matters, whether replay is needed, what the source platform can expose and how much operational complexity the organisation can support.

The accepted platform documentation shows these are already ordinary enterprise integration patterns. Dataverse supports change tracking using synchronisation tokens, webhooks and Azure Service Bus integration. Salesforce Pub/Sub supports change data capture and event-driven integration, with replay limited by event retention. SAP supports business-event publication and generated consumers based on AsyncAPI metadata. (Microsoft change tracking, Microsoft webhooks, Salesforce Pub/Sub API, Salesforce event durability, SAP event-based integration)

The transport should therefore be chosen per fact or change class, not once for the entire DPP.

A regulated static attribute that changes twice a year may be perfectly suited to controlled batch publication. A stock or status change might use CDC. A lifecycle event may belong on an event stream. A rarely requested record held in a performant source could be virtualised instead of replicated.

Identity and reconciliation checkpoints

Transport moves data. It does not prove that two records refer to the same thing or that the incoming value should win.

Before a change reaches publication, check at least four things:

1. Identity: Which entity does the source record map to?
2. Authority: Is this source allowed to assert this field for that entity and time period?
3. Version/effective state: Is the incoming assertion newer, corrective or simply late?
4. Reconciliation: Does it agree with other authoritative evidence, or must it enter conflict/review state?

ServiceNow's Identification and Reconciliation Engine is not a product-master standard, but it is a useful enterprise analogy: imported third-party data is transformed and reconciled rather than blindly creating duplicate or inconsistent configuration items. (ServiceNow IntegrationHub ETL)

The same principle matters in a DPP. A mapping should be explainable, and conflicting assertions should remain visible until resolved.

When a correction changes identity or product state, do not improvise the lifecycle rule inside the integration. Use the canonical guide on whether to overwrite a fact, version the record or create a new product.

Failure semantics: retries, duplicates, stale data and conflicts

The most expensive integration errors are often not spectacular outages. They are plausible records that are quietly wrong.

Retries can duplicate work

A source or consumer can retry after a timeout even when the first attempt actually succeeded. Consumer restarts can also cause messages to be processed again. Apache Kafka's idempotent-producer design history and Debezium's outbox pattern both treat duplicate-safe processing as deliberate engineering work, not something the transport gives you automatically. (Apache Kafka idempotent producer rationale, Debezium Outbox Event Router)

A DPP consumer should therefore be able to recognise the same change twice without creating two logical outcomes.

Event retention is not an audit log

Salesforce, for example, documents a 72-hour retention period for platform and CDC events in Pub/Sub replay. That is useful for recovery, but it is not a permanent product-history store. (Salesforce event message durability)

If you need durable audit history, persist the relevant checkpoint and publication evidence deliberately.

Arrival order is not authority

Two events can arrive out of order. A batch can complete after a more recent webhook. A downstream retry can surface an old state again.

The rule should never be simply "last message wins" unless the domain contract explicitly makes that safe. Compare source authority, version/effective time and reconciliation state before publication.

Failure needs a visible state

A robust DPP publication layer should distinguish, at minimum:

• successfully published;
• waiting for source data;
• validation failed;
• identity unresolved;
• conflict/review required;
• stale beyond an accepted threshold;
• retrying after transport failure.

Those states make operational problems observable instead of turning them into silent data quality drift.

Reference deployments and architectures

The accepted evidence shows that these patterns are already used in enterprise systems, but the examples should be read as architecture evidence, not universal performance or ROI proof.

• Zalando described its Smart Product Platform around event-driven product data and treated outbound events as part of the API contract. A later engineering account described moving complexity away from a central aggregation approach. These are useful examples of event-driven responsibility boundaries, but they are company-authored accounts from a specific architecture. (Zalando event-first development, Zalando distributing complexity)
• Catena-X / Eclipse Tractus-X EcoPass separates registry/discovery, submodel data and connector-based access. Some data-sovereignty concepts in the referenced documentation remain prototype-phase, so it is evidence of a distributed reference architecture rather than proof of universal cross-industry deployment. (EcoPass operation view, EcoPass business architecture)
• Akeneo customer cases show ERP-PIM-commerce integrations in production, including API-based synchronisation. Vendor-reported productivity outcomes in those stories are not independent ROI evidence and should not be generalised. (GSM55 customer story, DELFINGEN customer case)

The broader standards layer is also mature enough to support explicit contracts. OpenAPI 3.2.0 describes request/response APIs, while AsyncAPI 3.0.0 provides a protocol-agnostic description for message-driven APIs. Those standards help describe contracts. They do not guarantee correct delivery, authority or reconciliation. (OpenAPI 3.2.0, AsyncAPI 3.0.0)

DPP-specific interoperability is still evolving around these existing enterprise patterns. There is no single mandatory ERP-to-DPP integration protocol in the accepted evidence.

Implementation checklist

Before wiring ERP, PIM, PLM or event infrastructure into a DPP, check that you can answer each of these questions:

• [ ] Is source-of-record authority defined for every published fact?
• [ ] Are cross-system identifiers mapped explicitly using the product ID mapping model?
• [ ] Is each inbound record classified as master state, event, correction or derived publication state?
• [ ] Is the transport pattern chosen per change class rather than by habit?
• [ ] Can the consumer replay safely without creating duplicate logical outcomes?
• [ ] Are source version, effective time and last successful checkpoint retained where needed?
• [ ] Can the publication layer surface stale, conflicted, invalid or unresolved records?
• [ ] Can you explain why a published value won when two sources disagreed?
• [ ] Is event retention being mistaken for permanent audit history?
• [ ] Are downstream channel projections kept separate from the question of whether a DPP can replace a retailer product feed?
• [ ] If identity is used to enrich the passport from third-party services, is that handled as product identity becoming a join key for external data rather than hidden master-data ownership?
• [ ] If the product exposes actions or services, is that handed to the product-as-API-endpoint architecture rather than folded into the integration layer?

What to do now

Start with authority, then choose a propagation pattern for each fact or change class. Keep the DPP responsible for the governed publication view, reconciliation evidence and operational control state.

The critical boundary is simple: store enough to publish and prove the view, but do not let the DPP quietly become a second product master.

Sources and evidence boundary

The core evidence for this article comes from GS1 EPCIS, GS1 Resolver and GS1 Digital Link standards; SAP, Microsoft, Salesforce and ServiceNow integration documentation; Debezium and Apache Kafka reliability patterns; and the Eclipse Tractus-X EcoPass reference architecture. Together they establish that master data, events, APIs, CDC, virtualisation, reconciliation and distributed resolution can be separated in real enterprise architectures.

The named Zalando and Akeneo deployments show that event-driven and ERP-PIM-commerce integration patterns are used in production. They do not prove a universal architecture, universal ROI or that a DPP should adopt any vendor's implementation unchanged.

• GS1 EPCIS Standard 2.0
• GS1-Conformant Resolver Standard 1.2.1
  Standards body
• APIs for Product Master, S/4HANA Cloud 2608 docs, SAP
• Develop Event-Based Integration, SAP
• Use change tracking to synchronize data with external systems, Microsoft
• Use Webhooks to Create External Handlers for Server Events, Microsoft
• Power Platform developer introduction: virtual tables, Microsoft
• Salesforce Pub/Sub API
• Salesforce Event Message Durability
• IntegrationHub ETL, ServiceNow
• OpenAPI Specification 3.2.0, OpenAPI Initiative
• AsyncAPI Specification 3.0.0, AsyncAPI Initiative
• Debezium Outbox Event Router
• Apache Kafka idempotent producer rationale, Apache Software Foundation
• Event First Development: Smart Product Platform, Zalando Engineering
• Simplicity by Distributing Complexity, Zalando Engineering
• Culinary Collaborations LLC traceability case study, GS1 US
• Tractus-X EcoPass Operation View, Eclipse Tractus-X
• Tractus-X EcoPass Business Architecture, Eclipse Tractus-X
• Akeneo GSM55 customer story
• Akeneo DELFINGEN customer case