Match rules tell UnifyApps how to spot duplicate records — such as the same customer or company entered twice from different sources — and what to do once it finds them. You define the conditions that count as a match, then choose whether matching records merge automatically, wait for a human to review them, or get scored and routed based on how confident the match is.
Overview
Each match rule lives on an entity inside a model and compares incoming records against your existing golden records, field by field. You build the rule around a simple grammar — Any of the following is true… or All of the following are true… — and pick a comparison method for each field you include. Before you can build a rule, the entity needs fields defined; if it doesn't, the screen shows No Entity Fields Defined instead of the rule builder. Creating a rule with New Match Rule also requires edit access to the model — without it, the button doesn't appear at all.
Match Operators
For each field you add to a rule, choose how strictly two values need to line up before they count as a match:
| Operator | When two records match |
| Exact Match On | The values are completely identical. |
| Exact or Null On | The values are identical, or at least one of them is empty. |
| Exact or All Null On | The values are identical, or both of them are empty. |
| Fuzzy Match On | The values are similar but not exactly identical — useful for typos, abbreviations, or formatting differences. |
Each field also has Rule Settings, where you can fine-tune advanced matching behavior and how the values are pre-processed before comparison.
Building a Match Rule
Under New Match Rule, you work through three steps:
Define Rule — choose Any of the following is true… if a match on even one condition should count as a duplicate, or All of the following are true… if every condition needs to match. Then add the fields and match operators that make up those conditions.
Define Merge Policy — decide what happens once a match is found (see below).
Filters — restrict which records the rule runs on, so it only evaluates the subset you care about.
Merge Policy
The Define Merge Policy step controls what happens to records once your rule identifies them as a match:
Automatically Merge — the records merge as soon as the matching condition is met, with no manual step in between.
Flag for Review — the matching pair is queued in Potential Matches for a data steward to review and resolve. It never merges on its own.
Relevance Based Action — instead of a flat yes/no, UnifyApps generates a match score between 0 and 1 (1 being a perfect match) from the comparators used on each field. You set two threshold ranges using sliders, in steps of 0.1: one for Flag for Review and one for Auto-Merge. A record's score determines its fate: if it falls in the auto-merge range, it merges; if it falls in the review range, it's flagged; if the two ranges overlap, flagging always takes precedence; and if the score lands outside both ranges, no action is taken at all.
Merge policy only decides whether and how records merge — it doesn't decide which field values survive into the merged record. That field-by-field decision, including strategies like prioritizing a source system or the most recent update, is covered on the separate Survivorship page.
Notes
If nothing merges even though records clearly match, check the merge policy on the rule that fired. Flag for Review is expected to wait in Potential Matches — it's not a bug.
With Relevance Based Action, scores outside both threshold ranges get no action at all — they're neither merged nor flagged, so they can silently sit unresolved.
If you want hands-off consolidation, use Automatically Merge, or widen the Auto-Merge threshold range so more matches fall inside it.
A blank rule builder that only shows No Entity Fields Defined means the entity needs fields set up before you can define a match rule.
The New Match Rule button is hidden rather than disabled if you lack edit access to the model — you won't see an explanation on screen.