Working with Matching

Matching and merging are automatically performed in ONE MDM based on predefined rules set in the matching configuration (that is, the configuration of the Matching step within the matching plan).

In cases where automated matching runs into ambiguities or constraints, and in the case where some special proposal rules are defined in the matching configuration, matching proposals are generated instead and need to be resolved manually. Even when proposals are generated, the instance record is still automatically processed (a master_id is assigned and the golden record is created), ensuring data remains accessible while awaiting manual resolution.

This behavior can be customized through solution-specific configuration of the model and filtering between instance and master layers.

You’ll rely more heavily on automated matching when:

For example, automated matching is commonly used if you’re dealing with similar data:

How effective automated matching is depends on the accuracy of the rule configuration and the quality of the processed data. In situations where records are incomplete or automated matching does not produce the desired results, it is possible to browse, compare, and merge records manually.

You can also create manual matching tasks for your team members, and perform split and rematch operations to refine matching outcomes.

During the manual matching process, the MDM Engine offers a merge preview, where you can see how the golden record would appear after the matching is performed. You can modify the result by selecting or entering new values (similar to the editing process).

As mentioned in the previous section, matching proposals, which are generated from automated matching, are also reviewed and resolved manually.

Manual matching is necessary for high-stakes decisions or complex cases but is limited to smaller volumes due to the individual review requirement. You’ll need more manual oversight when:

Typically, it is used for situations such as these:

Matching proposals represent a hybrid approach between automated and manual matching processes. They are generated as a result of automated matching and suggest potential duplicates but require manual resolution to confirm, reject, or adjust the suggested matches.

This resolution process is identical to the manual matching workflow. Additionally, you can search for related matching proposals and resolve them in bulk.

Matching proposals are generated when:

For details, see Matching Proposals.

Changes to record identities can be initiated using the following methods:

As a best practice, focus on identifying suspicious or uncertain matching cases, such as significant data change events or potentially problematic matches, rather than attempting to automate their resolution. Automatic resolution of such scenarios typically produces unpredictable results and ultimately requires manual intervention, making the initial automation attempt counterproductive.

Rematching allows you to reassess (and potentially alter) existing matching decisions when rules change or data quality improves. It can be initiated through various mechanisms within the MDM system:

By default, inactive records are included in the matching process and treated the same as active records. However, in the mastering phase, inactive records are often filtered out and not used in the computation of golden records.

If the source deletion strategy is set to delete, inactive records are removed from the MDM storage entirely and not considered in any consolidation operations (that is, cleanse, match, merge). This ensures that only relevant and active data contributes to the golden records.

The advantage of including inactive records is maintaining continuity. For example, if a client returns after a contract termination, the inactive record retains its master ID during the inactive period. In other words, when the client returns, this ID can be reused, preserving the customer identity.

In centralized and mixed MDM implementation styles, instance records can be matched to authored master records that exist only at the master layer. This ensures that incoming instance data can be properly associated with manually created master records.

However, authored master records themselves cannot be matched to other existing records through the standard matching process. Instead, they are identified through the Identify action in the web application or using the IdentifyMaster service.

When creating new authored master records, MDM populates duplicate_id values to flag potential duplicates, but this identification process is separate from the matching workflow. A specific configuration is required on the master entity to map attributes from the master layer to the Matching step for this functionality to work.