Match Policies
A match policy defines what "the same person" means for one datastore. It is the most valuable thing you can configure in a CRM and the thing most often left until the data is already a mess.
Where to find it
Architect Panel → Data:
- Match Policies — the policies and their thresholds
- Match Policy Fields — the fields compared and their weights
- Datastores — the datastore a policy applies to
Architect Panel → Automation:
- Tasks — Duplicate Detection Sweep, daily
What a policy holds
- A key and label.
- The datastore it applies to.
- A review threshold and a block threshold.
- Criteria limiting which records are considered.
- An enabled flag.
Fields are weighted
Each field in the policy carries a comparison method, a weight, and whether it is required. Comparing two records produces a total score from the fields that agree.
Weighting is what makes this work. A matching e-mail address is strong evidence; a matching first name is almost none. Giving them equal weight produces either a flood of false matches or a policy that misses real ones.
Weight by how identifying a field is
- High — e-mail address, mobile number, customer reference, national identifier.
- Medium — surname with postcode, organisation with full name.
- Low — first name, town, job title.
The question to ask of each field is: if two records agree on this and nothing else, are they the same person? If the answer is clearly no, the weight is low.
Required fields
Marking a field required means no match is considered without it. Useful for narrowing an expensive comparison, and dangerous if the field is often blank — a required e-mail address means two records for somebody with no e-mail will never be matched.
The two thresholds
- Review threshold — at or above this score, the pair is raised as a candidate for a person to look at.
- Block threshold — a higher score, at which the match is treated as certain.
The gap between them is your uncertainty band, and it should be wide enough to catch genuine ambiguity without burying reviewers in obvious cases.
Set the block threshold high
Whatever happens automatically at the block threshold should only happen when you are genuinely certain. Two people at the same company with similar names are a real and common case, and treating them as one is a worse outcome than a duplicate.
When in doubt, lower the review threshold rather than the block threshold. More review is cheap; a wrong automatic decision is not.
Tune with real data
Run the policy against your existing records and look at what it produces before enabling anything automatic. Check both directions: pairs it raised that are not duplicates, and known duplicates it missed.
Configure it before loading data
Duplicates are far cheaper to prevent at entry than to merge later, and every integration you connect will create them faster than people do.
Worked example
A policy on People weights e-mail at 60, mobile at 50, surname plus postcode at 30 and first name at 5, with a review threshold of 60 and a block threshold of 100. Matching e-mail alone reaches review; e-mail plus mobile is treated as certain. Running it over 40,000 existing records raises 900 candidates, of which about 700 turn out to be genuine.
Recommendations
- Weight by how identifying each field is.
- Set the block threshold conservatively high.
- Tune against real data before enabling anything.
- Configure it before loading, not after.