Matching Criteria Overview
  • 09 Aug 2024
  • 1 minute read
  • Dark
    Light
  • PDF

Matching Criteria Overview

  • Dark
    Light
  • PDF

Article summary

When you import something into Slate, like a person record or an application, Slate tries to prevent duplicate records from being created.

To prevent duplicates, Slate evaluates matching criteria.

  • Slate does this in a specific order that correlates to the quality of the data being evaluated.

  • It helps when troubleshooting to be aware of the order that Slate evaluates matching criteria.

  • You might import person records, dataset records, or system objects associated with those records. Slate has different matching criteria for each of these types.

The articles in this section describe the unique orders in which different types of records are evaluated for matching criteria.

Person and dataset records

For person and dataset records, as soon as a record matches a mapped item, Slate considers the record to be found and stops evaluating subsequent matching criteria.

📖 Further reading

Application records

When importing application data, Slate attempts to match incoming person records to any existing person records. Slate will also match an existing application if application matching criteria are mapped as part of the import and they match an existing application record.

📖 Further reading

Matching Criteria for Application Records

System objects

System objects include information like addresses, jobs, relationships, gifts, and entities. These objects exist in relation to person, dataset, or application records.

When you import system objects, they either overwrite the data of on an existing person or dataset record, or the imported objects are discarded to avoid creating duplicate system objects. For example, an imported address will always be added as new on a record unless it has the same address type, priority, street, postal code, city, and country.

📖 Further reading


Was this article helpful?