Master data management in Business Central

For Business Central tenants running multiple companies — sister entities sharing items, customers, vendors, and other master data — keeping them in sync used to mean either painful manual maintenance, custom scripts, or external middleware. Master Data Management (MDM), a feature Microsoft added to Business Central, builds the synchronisation natively. It's not as sophisticated as a dedicated MDM platform but covers the common multi-company scenario well.

The source/subscriber model. One company is designated the source for a given master data type — typically the "headquarters" or "main" company. Other companies in the same environment are subscribers. Master records created or updated in the source automatically synchronise to the subscribers, optionally with field-by-field control over what synchronises.

Synchronised entities. The most commonly used:

• Items — item card, item variants, item references, base unit of measure, prices.
• Customers — customer card, contacts associated with customer.
• Vendors — vendor card, contacts associated with vendor.
• Items, customers, vendors are by far the most common; additional tables can be synced through configuration.

Field-level control. Not every field on the source item should land on every subscriber. The base unit, item number, and description should sync; the inventory posting group might be per-company because each subsidiary uses different GL structures. The MDM configuration lets administrators include or exclude specific fields per subscriber.

Synchronisation cadence. Sync can run on demand (administrator triggers it), scheduled (job queue runs it nightly), or on change (record-level events propagate immediately). Most tenants run scheduled sync nightly with on-demand for urgent changes.

Conflict resolution. What if a subscriber edits a synchronised field on their copy? Two configurable policies:

• Source wins — the next sync overwrites the subscriber's edit. The default, and the safest for items where the master must rule.
• Subscriber wins — the subscriber's edit is preserved and the field stops syncing for that record. Used when subscribers genuinely need local override.

Conflicts are logged for administrator review, regardless of policy.

Operational realities.

• Initial sync can be large — the first run pushes thousands of items to subscribers. Schedule during quiet hours.
• Posting groups, dimensions, and country-specific fields are usually subscriber-local. Don't sync them.
• Number series are subscriber-local. The source's customer number won't necessarily match the subscriber's, so the sync uses field mapping rather than numeric equality.
• Removing a subscriber requires care — break the sync first, then archive subscriber-local data.

Limits.

• MDM in BC is intra-environment, intra-tenant. Cross-tenant or cross-environment sync needs middleware (Power Automate, Logic Apps, an iPaaS tool).
• Complex multi-level relationships (item → BOM → component items) need deliberate sync ordering.
• Hierarchical master data (parent/child customers) syncs but requires the parent to land first.

When to outgrow. Beyond ~30 companies with complex hierarchies and cross-system MDM, customers typically introduce a dedicated MDM platform (Profisee, Stibo, Reltio, Riversand) feeding BC instead of using BC's own MDM. For most multi-company SMBs in the under-20 entity range, the built-in MDM is the right answer.