Hi,
I want my data stewards to be able to create objects in the application, and then for these objects to go through the match-and-merge process sometime down the line when a downstream database contributes some source data.
For example: I have an Allocation golden record that needs to be initially created in the application. A few days later, records in an operational database will be created that reflect the creation of an Allocation-like object in that database. I load that object into the xDM app.
Now I have two records:
* 1 source authoring record and corresponding (DE_BASED) golden record
* 1 source record (the operational database's) and corresponding (MASTER_BASED) golden record.
These should ideally be matched and merged, as they refer to the same thing.
My question is - can I apply match & merge mechanics to the DE_BASED record here? Can I even use a duplicate manager with that record? Or am I required to use master authoring initially to produce a manually-generated MASTER_BASED golden record initially?
Thanks
Best Answer
S
Stephanie Fourrier
said
9 months ago
Hi Michael,
thanks for this detailed explanation of your issue.
You got it perfectly: Match and Merge are applied during the job certification only between master records. You have to let your data steward author Master Records in the hub instead of DE_BASED records if you want future incoming master records to match with it.
To answer your side note about DE_BASED records and applying Match and Merge on them, there is one use-case where you can prevent the creation of a DE_BASED record while being created if it is matching with an existing Master Record: the DETECT_DUPS stepper validation is the one you can choose to prevent this duplicate creation.
Last but not least, the use-case for UI records creation, then incoming master records is not recommended by our consultants by default, as the users might not know where they should create the records. This could be a bad practice. There are some cases where it makes sense but I would recommend you reach out to our expert consultants to double-check your use-case.
I hope this helped.
Best regards,
Stéphanie.
1 Comment
S
Stephanie Fourrier
said
9 months ago
Answer
Hi Michael,
thanks for this detailed explanation of your issue.
You got it perfectly: Match and Merge are applied during the job certification only between master records. You have to let your data steward author Master Records in the hub instead of DE_BASED records if you want future incoming master records to match with it.
To answer your side note about DE_BASED records and applying Match and Merge on them, there is one use-case where you can prevent the creation of a DE_BASED record while being created if it is matching with an existing Master Record: the DETECT_DUPS stepper validation is the one you can choose to prevent this duplicate creation.
Last but not least, the use-case for UI records creation, then incoming master records is not recommended by our consultants by default, as the users might not know where they should create the records. This could be a bad practice. There are some cases where it makes sense but I would recommend you reach out to our expert consultants to double-check your use-case.
Michael. guenot
Hi Michael,
thanks for this detailed explanation of your issue.
You got it perfectly: Match and Merge are applied during the job certification only between master records. You have to let your data steward author Master Records in the hub instead of DE_BASED records if you want future incoming master records to match with it.
To answer your side note about DE_BASED records and applying Match and Merge on them, there is one use-case where you can prevent the creation of a DE_BASED record while being created if it is matching with an existing Master Record: the DETECT_DUPS stepper validation is the one you can choose to prevent this duplicate creation.
Last but not least, the use-case for UI records creation, then incoming master records is not recommended by our consultants by default, as the users might not know where they should create the records. This could be a bad practice. There are some cases where it makes sense but I would recommend you reach out to our expert consultants to double-check your use-case.
I hope this helped.
Best regards,
Stéphanie.
Stephanie Fourrier
Hi Michael,
thanks for this detailed explanation of your issue.
You got it perfectly: Match and Merge are applied during the job certification only between master records. You have to let your data steward author Master Records in the hub instead of DE_BASED records if you want future incoming master records to match with it.
To answer your side note about DE_BASED records and applying Match and Merge on them, there is one use-case where you can prevent the creation of a DE_BASED record while being created if it is matching with an existing Master Record: the DETECT_DUPS stepper validation is the one you can choose to prevent this duplicate creation.
Last but not least, the use-case for UI records creation, then incoming master records is not recommended by our consultants by default, as the users might not know where they should create the records. This could be a bad practice. There are some cases where it makes sense but I would recommend you reach out to our expert consultants to double-check your use-case.
I hope this helped.
Best regards,
Stéphanie.
-
Can we reset Matches and run again on match rule change or add a new match rule?
-
"Unmerge" records
-
Turn off match rules to speed up an integration job
-
Can anyone tell me how to load a Fuzzy-Matched entity ... but skip the matching happening auto-magically?
-
Importing CSV in Fuzzy Matched Entity Does Not Trigger Consolidation
-
How can I trigger a "match on child records"?
-
How can I Configure Most Frequent Values in Survivorship Rules?
-
Deterministic or probabilistic matching
-
Machine Learning and AI for matching
-
Prevent loads from replacing values overridden by users
See all 36 topics