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 can't 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. The majority of the match groups implemented across customers' configurations use, mainly, a rule for their matching goals. But, in some situations, it is advantageous to additionally dedicate one, or more, match groups to support a negative rule, for the purpose of stopping a merge-based rule (usually, on a single condition). And, when that condition is met, the negative rule prevents any other rule from merging the records. For example, you might have seven match groups, each of which use a rule, while the eighth group uses a negative rule.

Important: 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. Negative rule will not impact suspect matches.

Negative rule supports the following nested operands:

notExactSame
notFuzzySame
or
and
equals
notEquals
nullValues

When using the equals and notEquals operands inside negative match rules, ensure they have only one condition for each attribute (example below).

"equals": [ { "values": [ "DL" ], "uri": "configuration/entityTypes/Individual/attributes/Identifiers/attributes/ID" } ]

Note: The negative rule doesn't support the not operand.

It's possible to combine multiple attributes for notExactSame and notFuzzySame operands. They are combined using a and operator, when you build the negative condition. The resulting operands are also combined using a and operator. For example, we'd be looking to find cases where both LastName and FirstName are not true.

Use case - Negative Rule

Consider the four profiles simply described below, which you want to find through your match rules:

Profile 1 (P1) - Andrew, Finnegan, 565-771-8801
Profile 2 (P2) - Andrew, Phinnegan, 565-771-8801
Profile 3 (P3) - Andrew, Finnigan, 565-771-8801
Profile 4 (P4) - Andrew, Finigan, 565-771-8802

Using straightforward 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 P4 is questionable as its SSN is different from that of the other three profiles.

If you added into the rule an Exact operator for SSN, you could comfortably use an automatic rule type. But, in this case, you lose P4 from the automatic merge, and may never know that it even exists, and that it may represent the same person as the other three profiles.

The negative rule gives you an automatic rule type, while downgrading it to the behavior of a suspect rule, if one or more attributes are problematic. The notExactSame comparison operator is often used in a negative rule.

In the example configuration below, any combination of P1, P2, P3 from above will evaluate to true and automatically merge. But, P4 when paired with any of the others or with the consolidated profile of [P1,P2,P3] 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 P4 will not be merged into [P1,P2,P3] but instead is paired with [P1,P2,P3] as a case of queued 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": [
                    "configuration/entityTypes/Individual/attributes/FirstName"
                ],
                "fuzzy": [
                    "configuration/entityTypes/Individual/attributes/LastName"
                ]
            }
        }
    },
    {
        "uri": "configuration/entityTypes/Individual/matchGroups/BySSN",
        "label": "Individuals not match by SSN",
        "type": "automatic",
        "negativeRule" : {
            "notExactSame": [
                "configuration/entityTypes/Individual/attributes/SSN"
            ]
        }
    }
]

Unify and manage your data

Negative Rule

Use case - Negative Rule

Footer