A match and merge solution takes ownership over the data and is well suited to data hub implementations with any degree of centralized or decentralized management of data.
For details on configuration, see the Match and Merge Traceability topic (here) and the Configuring Match and Merge topic (here).
In the following sections, an example of maintaining customer records in a match and merge solution is used to explain the match and merge data functionality.
Data Model
Unlike the Match and Link Match Action, in the Match and Merge Match Action the source record and golden record do not use separate object types.
Information Flow
When a customer record is created or updated in an external system, the update is delivered to STEP via either a web service endpoint or an IIEP.
In both cases, the incoming source record is matched against the existing golden records, and if a match is found, the information from the source record is merged into the relevant golden record using survivorship rules. If this results in updated information, the customer record can be exported back to all external systems. In this way, an update to the customer record in any system can be automatically managed for trust and timeliness and ensures that the best possible view of the customer record is reflected across the entire ecosystem.
When a user updates the customer record in STEP, the update takes place on the golden record itself, and the new trusted record can be exported in the same way as before.
The matching process uses a 'match score' within three groups separated by thresholds to indicate the likelihood of a match.
-
A match score above the auto threshold (the highest threshold) is considered a match and the system automatically merges the data. The matching algorithm declares one of the records as the 'survivor' and deactivates the other record. Information from the deactivated record is merged into the surviving record based on the survivorship rules set on the matching algorithm.
-
A match score between the clerical review threshold and the auto threshold indicates a possible match. The two records are sent to the clerical review workflow so a user can determine if there is a match or not. The data steward manually confirms the two records are duplicates and merges them or confirms they are not duplicates and should be kept separate going forward.
-
A match score below the clerical review threshold (the lowest threshold) is considered a non-match.
As golden records are created or updated, a matching event processor compares the golden record to other golden records in the system.
Even in the best organizations, accidents happen. When two records are merged accidentally, STEP has tools to help resolve the issue. In a data hub that is closely integrated with a multitude of source systems, the process of unmerge may require a range of activities in the workflow in addition to the actual unmerge Web UI. The unmerge Web UI uses both original source records from source systems, revision history, and the match algorithm survivorship rules to help the user determine which values belong to which records during an unmerge.
