Integration patterns for PLM, ERP, PIM and DAM: flows, identifiers and master data ownership

Ownership decides integration quality more than technology does

Integration projects fail most often on unclear ownership, rarely on transport technology. Before choosing a pattern, an architecture team should decide which system creates, which system enriches and which system only consumes each attribute group. Two systems that both write the same field will overwrite each other, whatever middleware sits between them. A one-page ownership matrix, agreed by product, supply chain and marketing, prevents most downstream defects.

Ownership should be recorded at attribute group level, such as dimensions, materials, prices or marketing copy, and reviewed whenever a new system or channel joins the estate. The matrix then becomes the specification that integration developers build against.

The canonical flow runs from PLM to ERP to PIM to channels

Product data follows the lifecycle. PLM defines the product during design, ERP makes it buyable and shippable, PIM makes it sellable and the channels publish it. DAM runs alongside PIM and supplies images, videos and documents linked by product identifier.

Compliance data increasingly starts in PLM. Packaging materials for PPWR and substance data for REACH flow through PIM to channels and passports, which is why the packaging data model belongs in integration design from day one. For the DAM link specifically, see DAM and PIM integration.

Four integration patterns fit different scales

Each pattern suits a different estate size and rate of change.

• Point-to-point: direct connections between pairs of systems. Fast to build for two or three systems, but connections grow quadratically. Six systems connected directly can need up to 30 one-way interfaces.
• iPaaS (integration platform as a service): a central platform with prebuilt connectors, mapping and monitoring. Suits mid-sized estates with five to fifteen systems and a small integration team.
• Event-driven: systems publish changes such as "product released" or "price changed" to an event broker, and subscribers react. Suits high volumes and near real-time needs, and decouples release cycles.
• API-led: layered APIs (system, process and experience) expose reusable services. Suits organisations with many consumers of the same data and a mature API practice.

Most estates combine patterns. A common setup uses events for change notifications, APIs for on-demand lookups and scheduled bulk transfers for initial loads and full catalogue syndication.

Identifiers hold the stack together

Stable identifiers matter more than any connector. Each system needs a cross-reference to the others, and that mapping must survive renumbering, mergers and system replacement.

Practical rules:

1. Assign the internal product key in the system of origin, usually PLM or ERP, and never reuse it.
2. Use the GS1 GTIN for the sellable trade item and keep GTIN allocation rules consistent with GS1 standards.
3. Store variant and packaging hierarchy relations explicitly: each, inner, case and pallet.
4. Link assets by product key, never by file name.
5. Keep a cross-reference table where systems use different keys, owned by a named data steward.

For consumer-facing and regulatory use, the GS1 Digital Link standard turns these identifiers into web addresses, which DPP data architecture with GS1 Digital Link explains in detail.

Sequence the integration build by data dependency

Build interfaces in the order that data originates. ERP to PIM usually comes first because it delivers the article backbone. PLM to PIM follows for specifications and compliance attributes, then DAM to PIM, then PIM to channels.

As an estimate, each production-grade interface with mapping, error handling and monitoring takes 10 to 40 person-days, depending on data complexity and the quality of the source APIs. Teams that agree ownership and identifiers before building typically need fewer rework cycles and reach go-live faster.