Negative Rule

A negative rule allows you to prevent any other rule from merging records.

A match group can have a rule or a negative rule. It cannot have both. The negative rule has the same architecture as a rule, but has the special behavior that if it evaluates to true, it will demote any directive of merge coming from another match group to queue for review. To be sure, most match groups across most customers’ configurations use a rule for most matching goals. But in some situations it can be advantageous to additionally dedicate one or more match groups to supporting a negative rule for the purpose of stopping a merge based on usually a single condition. And when the condition is met, the negative rule prevents any other rule from merging the records. So in practice, you might have seven match groups each of which use a rule, while the eighth group uses a negative rule.

Consider the four profiles simply described below, and you wish them to be found by your match rules.

Andrew, Finnegan, 565-771-8801

Andrew, Phinnegan, 565-771-8801

Andrew, Finnigan, 565-771-8801

Andrew, Finigan, 565-771-8802

Using obvious elements such as Fuzzy (FirstName, LastName) in a suspect rule type with the Soundex comparator used for the Fuzzy element, these four form a pretty good set of matches for data stewardship review. But automation is always better if possible and so it would be great if the rule could be set to automatic, to produce an automatic merge. The trouble is that profile #4 is questionable due to the SSN not being the same as the others.

If you added into the rule an Exact operator for SSN, you could comfortably use an automatic rule type. But then you lose profile no. 4 from the automatic merge and may never know that it even exists and that he might be the same person as the other three.

The negative rule gives you another option. The negative rule empowers you to take advantage of an automatic rule type, while downgrading it to the behavior of a suspect rule if one or more attributes are problematic in some way that you define. The notExactSame comparison operator is often used in a negative rule.

In the example configuration below, any combination of profiles 1, 2, 3 from above will evaluate to true and automatically merge. But profile #4 when paired with any of the others or with the consolidated profile of [1,2,3] will evaluate to true for notExactSame and thus cause the negative rule to also evaluate to true. This then causes any other automatic rule within matchGroups to be treated as a suspect rule. The outcome is that profile #4 will not be merged into [1,2,3] but instead will be paired with [1,2,3] as a case of queue for review, and displayed in the Hub as a Potential Match.

Example configuration:

"matchGroups": [
        "uri": "configuration/entityTypes/Individual/matchGroups/ByName",
        "label": "Automatic individual match by name",
        "type": "automatic",
        "rule": {
            "or" : {
                "exact": [
                "fuzzy": [
        "uri": "configuration/entityTypes/Individual/matchGroups/BySSN",
        "label": "Individuals not match by SSN",
        "type": "automatic",
        "negativeRule" : {
            "notExactSame": [
Note: IMPORTANT: While supported, use of the negative rule is not generally encouraged because it governs the directives of ALL the other rules across your match groups which many customers find undesirable. The primary benefit of the negative rule is that it can demote a merge directive coming from any rule to a queue for review directive.You can achieve a similar effect more granularly by creating a set of rules of type auto and another set of type suspect, and additionally using a combination of not and notExactSame within a rule.