Advanced Match Rules
The match rules have access to a certain number of attributes:
Attributes from the entity being matched.
Attributes from related parent entities of the entity being matched.
Attributes from related child entities of the entity being matched.
Using these three type of attributes, you can configure both simple and complex match rules for advanced matching patterns.
This capability is available for all entities.
You can access attributes from the parent entities using regular SemQL expressions.
For example, if you have a Contact entity with a parent Customer entity, and want to match contacts when they work for customers with the same name, you would use the following syntax:
Record1.Customer.Name = Record2.Customer.Name
Note that in this expression, Customer is the role name of the customer entity in the relationship.
A common pattern when matching on parent records is a self-referencing entity, that is an entity with a reference pointing to itself.
For example, a Folder entity with a FolderName attribute and a ParentFolder foreign attribute pointing to the same Folder entity.
Matching folders with the same FolderName under the same ParentFolder requires two match rules:
A rule for the root folders, matching on FolderName those of the records that have both null source ID and source publisher values (PublisherID_ParentFolder and SourceID_ParentFolder):
Record1.PublisherID_ParentFolder is null and Record1.SourceID_ParentFolder is null and Record2.PublisherID_ParentFolder is null and Record2.SourceID_ParentFolder is null and Record1.FolderName = Record2.FolderName
This rule does not check that
FID_ParentFolder is nullas it will be the case for all the records during the first load (the FID is the result of the consolidation). Using PublisherID_ParentFolder and PublisherID_ParentFolder works in all cases.
A rule for the child folders, matching on FolderName the records under the same consolidated golden parent (same FID_ParentFolder):
Record1.FID_ParentFolder is not null and Record2.FID_ParentFolder is not null and Record1.FID_ParentFolder = Record2.FID_ParentFolder and Record1.FolderName = Record2.FolderName
With this type of match rule, when the golden ID of a folder changes (for example, because it merges into another folder) a notification is stored for the child records of this folder. The next time the Folder entity is processed, these child records will be automatically re-processed and possibly merge with their new siblings.
You can automate such post-processing using the
PARAM_CHILD_POSTPROCESSING_JOB job parameter. This parameter detects such notifications and triggers a job as needed to process the child records.
This capability is available only for fuzzy matching entities. You must declare in the rule the child entity used for matching.
For example, if you have a Contact entity with a child EmailAddresses entity and you want to match contacts using their email addresses, then you must configure a match rule in the Contact matcher with:
Match on Child Records checked.
Child Records set to EmailAddresses
Binning Expressions and a Matching Condition using attributes of the EmailAddresses entity.
Note also that if any pair of child records matches according to the rule, then the two parent records are matched.
For example, the following expression used in the match rule will match contacts when they have at least one matching email address.
Record1.Address = Record2.Address
Match rules that work to match master records in the certification process are also used to detect existing matches when a user creates a new golden record from an application.
If a match rule uses an attribute that is only available for master records and not for golden records (for example,
SourceID), then this match rule is entirely ignored when detecting duplicates during golden record creation in applications.