When you import something into Slate, Slate tries to prevent duplicates from being created. To prevent a duplication, Slate evaluates matching criteria. It does so in a specific order that correlates to the quality of the data being evaluated.

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

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. It’s important to be aware of the order in which Slate evaluates matching criteria.

📖 Further reading

• Matching Criteria for Person Records

• Matching Criteria for Dataset Records

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

• Matching Criteria for System Objects (Schools, Tests, Interactions, and more)

• Matching Criteria for System Objects (Gifts, Pledges, Opportunities, and more)