Use case — MDM & Integration
The same client, across five different systems.
The CRM turned it into two records, the ERP has a third with an abbreviated company name, and the billing system still uses the old account number. Until these identities are reconciled, no cross-functional metric is reliable — and as long as source context is lost along the way, no one trusts the result.
The situation
The same entity, described differently everywhere
Each system is right within its own scope. The problem appears when you want to count, compare or consolidate: identities don't match up, and manual reconciliation starts over every time.
The temptation is to flatten variants to produce a single record. That's precisely what makes the result questionable: as soon as a selection rule changes, nothing is verifiable anymore, and source systems no longer recognize themselves in the consolidated version.
What beVault provides
The business key as a convergence point
In a Data Vault, the business entity exists only once. Each system attaches its own reference to it without losing its own: reconciliation is additive, it doesn't replace.
- Business keys
- The chosen Business Key — company number, national identifier, combination of fields — is a decision documented in the model, not an implicit convention.
- Multi-source reconciliation
- Correspondences between identifiers from different systems are materialized through dedicated structures (same-as links), which are revisable and historized.
- Historization
- Original values remain kept and dated. A mapping revised later doesn't erase what was observed before.
- Survivorship rules
- Which source is authoritative for the address, for the company name: these rules are explicitly declared and applied, within the scope agreed with you.
- Traceability
- Each attribute of the consolidated view remains linked to the system it comes from, making it possible to justify a value rather than defend it.
The approach
One business object at a time
- 01
Choose the object and its sources
A single object — often the customer or the supplier — and three to five contributing systems. The actual duplicate rate is measured before any decision is made.
- 02
Identify and reconcile business keys
The chosen key is agreed with the business, then the correspondences between systems are established and materialized in the model.
- 03
Preserve source context and history
Values from each system remain stored as-is, dated and linked to their origin. Nothing is overwritten in favor of a single version.
- 04
Apply the validated survivorship rules
Where a rule has been defined and accepted, it produces an explainable reference value. Ambiguous cases go to human arbitration, with the context needed to decide.
- 05
Expose a governed view
The reference view is published for applications and reports, together with the Data Lineage of every attribute back to its source system.
The principle
A reference view is an interpretation, never a destruction.
If a survivorship rule changes in six months, it is updated and the outputs are regenerated: the original data is still there, intact and timestamped. This is what allows a decision to be revised without rebuilding the reference model.
Next step