Matching Criteria for System Objects (Schools, Tests, Interactions, and more)
  • 03 Apr 2024
  • 10 minute read
  • Dark
    Light
  • PDF

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

  • Dark
    Light
  • PDF

Article summary

When importing data to populate standard system objects such as schools, tests, and devices, Slate attempts to prevent duplicating system objects associated with the person, application, or dataset record. In many cases, matching system objects are updated based on the imported data, while in others, the data is removed from the process to avoid creating duplicate system objects. This article describes the process Slate uses to match or create each type of system object when imported.

Activities and Interactions

Interactions and activities never match existing interactions. Instead, they are added as new interactions, but they are deduped using two sets of criteria:

  • If an activity or interaction already exists for the record with the same code and the same source (meaning the same source file or form), then the interaction is not re-added.

  • If an activity or interaction already exists with the same code, subject, and date (or a date was not mapped), then the interaction is not re-added.

There are items that can be mapped to override these behaviors:

Source Field

Destination

Interaction: Allow Duplicate Interactions

Can be mapped to Yes on a form to allow multiple submissions of the same form to add the same interaction code.

Activity: Prevent Duplication or Interaction: Prevent Duplication

Can be mapped as a static value to No to prevent deduping using the second method described above. This can be useful if you have an import that maps the activity or interaction code and subject, but not a date, and you want the activity or interaction to be added each time the record is included in an uploaded file.

Activity or Interaction Creation

If the activity or interaction is not considered a duplicate, one is added as long as Activity: Code or Interaction: Code is mapped. If no date is mapped, the current date is used.

Addresses

Addresses do not match existing address objects. Instead, they are added as new addresses, but they are deduped first. Address, Mailing Address, and Permanent Address destinations all have the same import behavior. While items discussed in this section may reference Address specifically, the coinciding destinations for Mailing Address and Permanent Address will be the same.

An address is considered to already exist on the record if the address has the same:

  • address type

  • priority

  • street

  • postal code

  • city

  • country

Address Update

The Updated Date of an existing address is only modified if the "Address - Notes" destination is mapped and contains a value in the source data.

Address Creation

If an address does not yet exist, one is added as long as Address - City has been mapped and has a value and at least one of the following has been mapped and has a value: Address - Region, Address - Region Code, or Address - Country. If there is no country value for a new address, then the address is imported as a US address.

Decisions

Decisions do not match existing decision objects. They are added as new decisions, but they are deduped first using two sets of criteria:

  • If a decision for the application record already exists with the same source (such as a form or source file), then a new decision is not added.

  • If a decision for the application record already exists with the same decision code, then a new decision is not added.

There is an item that can be mapped to override the dedupe behavior for the first item above:

Source Field

Destination

Decision: Allow Subsequent Decisions from Same Source

Can be mapped to Yes on a form to allow multiple submissions of the same form to add different decision codes for the same application. If this is mapped to Yes, then editing an existing form submission to select a different decision code results in the addition of the new decision, provided that the application does not yet have the same decision code. The same is true for subsequent submissions of the same form for forms that allow multiple submissions, including Reader forms.

Decision Creation

If the decision in the import is deemed to not be a duplicate, then one is added as long as Decision: Code has been mapped and has a value.

Devices

Devices use two matching criteria to match an existing device on the record:

  • Device - GUID (Matching Only)
    This matching criteria allows updates to the type, value, priority, and notes.

  • Device - Value and Device - Type

    This matching criteria only allows updates to the priority and notes.

Device Update

The Updated Date of an existing device is only modified by an import if the data has changed from the existing values.

Device Creation

If the device does not yet exist, then a new device is added as long as both Device - Type and a Device - Value are mapped and have a value.

Form Registrations

If the record has a form registration for the exact same form that has been mapped, then the registration is updated. 

Form Registration Update

The Updated Date of an existing form registration is never modified by an import.

Form Registration Creation

If the registration does not yet exist, then a new form registration is added if a form has been mapped using either Form ID or Form Title.

Interests

Interests use two matching criteria to match an existing interest on the record. The criteria is evaluated in the following order, and once a match is found, no other matches are attempted:

  1. Interest - GUID Matching Only

  2. Interest - Name (Value)/Interest - Name (Prompt) and Interest - Type (Value)/Interest - Type (Prompt) and Interest - Role all match the existing interest object.

Interest Update

The Updated Date of an existing interest is never modified by an import.

Interest Creation

If a matching interest object is not found, then a new interest is created. An interest record requires a name, so Interest - Name (Value) or Interest - Name (Prompt) must be mapped and have a value for a new interest to be created.

Jobs

Jobs use two matching criteria to match an existing job on the record. The criteria is evaluated in the following order, and once a match is found, no other matches are attempted:

  1. Job: GUID Matching Only

  2. Job: Key

Job Update

The Updated Date of an existing job is never modified by an import.

Job Creation

If a matching job object is not found, then a new job is created. A job object requires an employer, so Job: Employer must be mapped and have a value for a new job object to be created.

Relationships

Relationships use multiple matching criteria to match an existing relationship on the record. The criteria is evaluated in the following order, and once a match is found, no other matches are attempted:

  1. Relationship: GUID Matching Only

  2. Relationship: External ID

  3. Relationship: First and Relationship: Last and Relationship: Type all match

Relationship Update

The Updated Date of an existing relationship is always modified by an import, regardless of whether any data was changed.

Relationship Creation

If a matching relationship object is not found, then a new relationship is created. A relationship object requires that at least one of the following has been mapped and has a value to be created: Relationship: FirstRelationship: Last, or Relationship: Email.

Schools

Schools use multiple matching criteria to match an existing school on the record. The criteria is evaluated in the following order, and once a match is found, no other matches are attempted:

  1. School: Guid Matching Only

  2. School: External ID

  3. School: Key or School: Name match and both of the following are true:

  • School: Degree matches the existing school object degree, or it is not mapped, or the existing school object does not have a degree.

  • School: Level of Study matches the existing school object level of study, or it is not mapped, or the existing school object does not have a level of study.

School Update

The Updated Date of an existing school is always modified by an import, regardless of whether any data was changed.

School Creation

If a matching school object is not found, then a new school is created. A school object requires a name, so School: Name must either be mapped or School: Key must be mapped, where an Organizations dataset record has a matching key.

If School: Key is mapped, a lookup is performed to capture the organization's name, city, region, and country. These items are used only in the absence of this data from the import. For example, if School: Location City is mapped and has a value for the school object, then the value from the import is used instead of the value from the Organizations dataset record. School: Location Region and School: Location Country are the other two mappable values that would override the Organizations dataset record location for the school object.

School Courses

Courses use multiple matching criteria to match an existing course on the record. The criteria is evaluated in the following order, and once a match is found, no other matches are attempted:

  1. School Course: GUID Matching Only

  2. School Course: External ID - The school object must also match using the criteria listed in the Schools section above.

  3. School Course: Name - The school object must also match using the criteria listed in the Schools section above, and all four of the following must be true:

  • School Course: Level matches the existing course's level, or it is not mapped, or the existing course object does not have a level.

  • School Course: Term matches the existing course's term, or it is not mapped, or the existing course object does not have a term.

  • School Course: Semester matches the existing course's semester, or it is not mapped, or the existing course object does not have a semester.

  • School Course: Grade Level matches the existing course's grade level, or it is not mapped, or the existing course object does not have a grade level.

Course Update

The Updated Date of an existing course is always modified by an import, regardless of whether any data was changed.

Course Creation

If a matching course object is not found, then a new course is created. A course requires a school - use the items outlined in the Schools section above to import or match a school object. School Course: Name must also be mapped and have a value for the course to be created.

Sports

Sports use multiple matching criteria to match an existing sport on the record. The criteria is evaluated in the following order, and once a match is found, no other matches are attempted:

  1. Sport - GUID Matching Only

  2. Sport - External ID (Note: This mapping can also be used to uniquely identify a Person record.)

  3. Sport - Sport

Sport Update

The Updated Date of an existing sport is never modified by an import.

Sport Creation

If a matching sport object is not found, then a new sport object is created. Sport - Sport must be mapped and have a value for the sport object to be created.

Test Scores

Test scores use multiple matching criteria to match an existing test score on the record. The criteria is evaluated in the following order, and once a match is found, no other matches are attempted:

  1. Test: GUID Matching Only

  2. Test: External ID and Test: Type

  3. Test: Type and Test: Date and Test: Verified and Test: Location all match

  4. If Test: Score Report is mapped to Yes:

  • Test: Type and Test: Date and Test: Location and all scores match and the existing score's status is Self-Reported and Test: Verified is mapped as Verified. Note: If Test: Score Report is mapped to Yes and a Self-Reported score exists on the record where the Test: TypeTest: DateTest: Location all match, and Test: Verified is mapped as Verified, and any of the scores do not match the existing score, then the existing score is updated to have the status Discrepancy.

Test score data can be mapped using the test-type-specific destinations and the generic test destinations. An example test-type-specific destination is Test: ACT - Date. An example generic test destination is Test: Date. For simplification purposes, this section of the article refers to the generic test destination mapping; however, both have the same behavior as long as a Test: Type is mapped and has a value when using the generic test destination mappings. When Test: Type is mentioned above, the test-type-specific destinations already automatically include the test type; however, for test types that use subtypes, the subtype must also be mapped (e.g., Test: AP - Subtype). 

When referring to Test: Date, the combination of Test: Date (month only) and Test: Date (year only) produces a date on the first of the month (e.g., 12/01/2017). This concatenated date then behaves the same as Test: Date.

Test Score Update

The Updated Date of an existing test score is never modified by an import.

Test Score Creation

If a matching test score object is not found, then a new test score is created. A test score requires a test type, so either a test-type-specific score must be mapped (with Test: {type} - Subtype mapped with a value, when applicable), or Test: Type must be mapped with a value. A test score also requires either a date or a score to be created, so either Test: Date must be mapped with a value, or one of the scores must be mapped with a value, such as Test: Total, Test: Score 1, or Test: Score 2.


Was this article helpful?