How Plex's parts master becomes D365 shared products and released products per legal entity, why product data design cannot start before the site-to-legal-entity topology decision is settled, and where automotive-specific attributes belong in the D365 product model.
The Plex parts master looks simple from the outside: a flat list of part records in a single multi-tenant tenant, each carrying attributes, a type classification, and cross-references to customers and vendors.
Plex models multiple sites inside one tenant. A part exists once and is visible everywhere. D365 uses legal entities as a hard boundary: a product must be explicitly released to each legal entity before it can be purchased, manufactured, or sold there. This is not a cosmetic difference — it changes the shape of the migration:
Product number — the unique identifier across all legal entities. Product type — Item (physical, stocked) or Service (non-stocked). Product subtype — Product (no variants) or Product master (carries variants through product dimensions).
Because Plex does not publish a data dictionary at the field level, the discovery relies on a tenant export. The following method applies regardless of extraction mechanism:
D365 offers four product dimensions: size, colour, style, and configuration. Each active dimension adds a column to the variant grid. The decision about which Plex attributes become product dimensions is irreversible once variants have been created and transacted.
Plex parts carry a unit of measure and (depending on tenant configuration) may have conversion factors between purchase, stocking, and sales units. D365 supports both global UoM conversions (the same factor applies to all items) and item-specific UoM conversions (a conversion defined for one released product).
Automotive suppliers commonly carry three categories of customer-specific data on or beside the Plex part record:
If Plex uses a classification or grouping on parts that simultaneously controls which GL accounts are posted to, which costing method applies, and how the part is categorised for reporting, that single Plex grouping must be decomposed into three D365 objects:
Every released product is assigned a storage dimension group and a tracking dimension group at the point of release. These determine which inventory dimensions are active — and once inventory transactions exist, the dimension groups cannot be changed.
The Plex parts master migration is not primarily a data-copy exercise. It is a design exercise that depends on the topology decision being settled, the item group decomposition being designed, and the dimension group architecture being locked — all before the first product record is loaded.