Matching Criteria for Person Records
  • 19 Aug 2024
  • 7 minute read
  • Dark
    Light
  • PDF

Matching Criteria for Person Records

  • Dark
    Light
  • PDF

Article summary

When person data comes in through a form or Upload Dataset, Slate tries to find an existing person record for this data, so as not to make a duplicate.

Slate looks for matching records based on a hierarchy of data called matching criteria. When it hits a matching criterion, it considers a match found and stops looking.

The order in which Slate evaluates criteria

The search for matching criteria for a person record follows three basic steps:

  1. App IDs: Look for matching application IDs on the candidate record

  2. Person data: If no matching application IDs, look for matching person data

  3. Create a new record: If none, create a new record

An additional matching step happens when Slate doesn’t find any matching application IDs for an incoming application, but does find matching person data:

  • Slate takes the incoming person’s application and looks at the round.

  • If the round of the incoming application matches the existing one, it updates the existing application.

You can override this behavior: Overriding application matching on round.

Calling off the search

When Slate finds a match, it stops evaluating matching criteria.

These criteria start with application data and end with biographic data, with a lot of other data in between. If Slate doesn’t find a match on the last criterion in this list (first name + last name + birthdate), it creates a new person record.

Let’s say your Upload Dataset data is mapped to both Slate application IDs and person-scoped Slate ID.

Because Slate evaluates application IDs earlier in the flowchart than person-scoped IDs, if the application Slate ID matches an existing application, the person-scoped Slate ID would never be evaluated for matching.

Initial search: Matching an existing application by ID

The items that are used to identify an existing person record in Slate appear below, in this order:

  1. App: Slate GUID Matching Only

    • This is the 36-character unique identifier of the application.

    • Matching only: Used only to find potential matches. Does not update the GUID.

  2. App: Application Slate Identity Matching Only

    • The integer value of the identity column on the application table.

    • Identity automatically assigned sequentially and cannot be updated.

    • Matching only: Used only to find potential matches. Does not update the Identity.

      📝 Note: This is an uncommon matching criterion and is only used in special cases.

  3. App: External ID

    • The external ID for an application.

    • If the external ID does not exist or a match was made from previously evaluated matching criteria, and the external ID does not match, then the external ID is updated.

  4. App: Application Slate ID Matching Only

    • The 9-digit application Ref ID.

    • Automatically generated for all applications upon creation.

    • Matching only: Used only to find potential matches. Does not update the Application Slate ID.

  5. Application-scoped unique custom fields

    • If the unique field value does not yet exist or does not match what was mapped in the source, the value is updated.

If app IDs don’t match: Matching person data

During the account creation process, the first name, last name, email, and birthdate values are required, and Slate only matches an existing record if there is an exact match on all four fields.

If none of the above items were mapped, or they do not match to an existing application, the following items are used to identify an existing person record:

  1. Slate GUID Matching Only

    • This is the 36-character unique identifier of the person.

    • Matching only: Used only to find potential matches. Does not update the GUID.

  2. Slate Identity Matching Only

    • The integer value of the identity column on the person table.

    • Identity automatically assigned sequentially and cannot be updated.

    • Matching only: Used only to find potential matches. Does not update the Identity.

      📝 Note: This is an uncommon matching criterion and is only used in special cases.

  3. Person-scoped unique custom fields

    • If the unique field value does not yet exist or does not match what was mapped in the source, the value is updated.

  4. Slate External ID

    • External ID for the person record.

    • If the external ID does not exist, or a match was made from previous matching criteria, and the external ID does not match, then the external ID is updated.

  5. Slate ID Matching Only

    • This is the Slate ID (Ref).

    • Matching only: Used only to find potential matches. Does not update the Slate ID.

  6. Slate ID Internal Matching Only

    • Automatically generated 9-digit Slate ID (Ref)

    • This uses only the automatically generated Slate ID, and it ignores any override ID that might exist for the record.

    • Matching only: Used only to find potential matches. Does not update the Slate ID.

  7. Slate ID Override

    • The Slate ID (Ref).

    • If a match was made from previous matching criteria, and the Slate ID does not match, then an override ID is set or updated for the record, and the Slate ID appears as this new value on the record.

  8. Sport - External ID

    • External ID for a sport record.

    • If a person record has any sport with this value as the external ID, a match occurs.

    • If the external ID does not exist, or a match was made from previous matching criteria, and the external ID does not match, then the external ID is updated for the sport.

  9. First + Last + Email

    • This is the combination of first name, last name, and rank #1 email address.

    • If there is an exact match, then this is used to match a person record.

    • If these did not match, but a match occurred previously (from other matching criteria), then these values are updated for that record.

      📝 Note: Email addresses on the device table that are not ranked #1 are not evaluated for matching.

  10. First + Last + Birthdate

    • Combination of first name, last name, and birthdate.

    • If there is an exact match, then this is used to match a person record.

    • If these did not match, but a match occurred previously (from other matching criteria), then these values are updated for that record.

    • If desired, this matching criteria may be disabled via the Merge (First+Last+Birthdate) Configuration Key.

If no matching person data: New person record created

If none of these items match, then a new person record is created if enough data was included for record creation (either email address or both first and last name).

Handling unmatched imported applications on existing person records

If an imported record:

  • has mapped application data, and

  • that data doesn’t match any existing applications in Slate, and

  • the record’s person data is then matched to an existing person record,

Then Slate tries to use the incoming application to update an existing application record on the matched person record.

The three items that override this behavior are described in Overriding application matching on round.

Slate uses the following criteria to update existing applications with incoming ones:

Round (or Round Override)

  • If Round (or Round Override) was mapped, Slate attempts to match an existing application that has that same round.

  • If an application in that round exists, that application is used for the import.

  • If an application in that round does not exist, a new application is created and assigned to the round that was mapped in the import.

Application Data

  • If application data was mapped, but a round was not mapped, then Slate uses the existing rank 1 application in an active application period for the import.

  • If the person record does not already have an application in the active application period, then no application data is imported.

  • Applications must be assigned a round to be created.

Overriding application matching on round

There are three items that can be used to override the application record matching criteria on round described in the preceding section.

These items are typically used as Static Mappings, as the intent is usually to perform this behavior for all records in the import. However, you can map a source field to these destinations to override the behavior conditionally based on a source value.

App: Round Always Create

  • When set to Yes, Slate always creates a new application using the round specified in the import.

  • It will not update an existing application.

App: Round Use Existing

  • When set to Yes, Slate uses the rank 1 application in an active application period, even if the round of the existing application does not match the round specified in the import.

App: Round Use Existing and Update

  • When set to Yes, Slate uses the rank 1 application in an active application period, even if the round of the existing application does not match the round specified in the import.

  • This setting also updates the existing application's round to what was mapped in the import.

📝 Note: If Slate was able to match to the application using the unique application fields described in the preceding person record matching criteria section, then these methods are not used because the application has already been identified.


Was this article helpful?