--- title: "Matching Criteria for System Objects (Gifts, Pledges, Opportunities, and more)" slug: "matching-criteria-for-system-objects-gifts-pledges-opportunities-and-more" updated: 2024-08-08T15:48:09Z published: 2024-08-08T15:48:09Z canonical: "knowledge.technolutions.net/matching-criteria-for-system-objects-gifts-pledges-opportunities-and-more" --- > ## Documentation Index > Fetch the complete documentation index at: https://knowledge.technolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # Matching Criteria for System Objects (Gifts, Pledges, Opportunities, and more) - Advancement When importing data to populate standard system objects such as gifts, addresses, and devices, Slate attempts to prevent the duplication of system objects associated with the person 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 details 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 the following 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), the interaction is not re-added. - If an activity or interaction already exists with the same code, subject, and date (or the date was not mapped), the interaction is not re-added. Some items 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/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 are deduped first. Address, Mailing Address, and Permanent Address destinations all have the same import behavior. While items described in this section can 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 Creation If an address does not yet exist, one is added if *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. --- ## **Devices** The device is not updated if the record has a device with the same device type and value. If the device type or value is changed, that device is updated. #### Device Creation If the device does not yet exist, then a new device is added if both *Device - Type* and *Device - Value*are mapped and have a value. --- ## **Entities** Entities use multiple matching criteria to match an existing object on the record. The criteria are evaluated in the following order, and once a match is found, no other matches are attempted: 1. *GUID* 2. *External ID* 3. *Identity* 4. *Custom unique for matching field scoped to the entity* #### Entity Creation A new entity will be created if a matching entity object is not found. An entity object requires at least one entity field to be mapped and have a value for a new entity object to be created. --- ## **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 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*. --- ## **Gift / Pledge / Planned** Gifts, Pledges, and Planned Gifts use multiple matching criteria to match an existing object on the record. The criteria are evaluated in the following order, and once a match is found, no other matches are attempted: 1. *GUID* 2. *External ID* 3. *Identity* #### Gift, Pledge, Planned gift Creation At a minimum, the acronym ***FAST***best describes the four required data points needed to create a gift, pledge, or planned gift: - *Fund* - *Amount* - *Status* - *Type* --- ## **Interests** Interests use two matching criteria to match an existing interest on the record. The criteria are 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 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 are 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 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. --- ## **Opportunities** Opportunities use multiple matching criteria to match an existing object on the record. The criteria are evaluated in the following order, and once a match is found, no other matches are attempted: 1. *GUID* 2. *External ID* 3. *Identity* #### Opportunity Creation If a matching opportunity object is not found, then a new opportunity is created. An opportunity object requires a summary (name). This destination must be mapped for a new Opportunity to be created. --- ## **Relationships** Relationships use multiple matching criteria to match an existing relationship on the record. The criteria are 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 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: First*, *Relationship: Last*, or *Relationship: Email*. --- ## **Schools** Schools use multiple matching criteria to match an existing school on the record. The criteria are 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 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, whereas 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 would be 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 are 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 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 are 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 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 are 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: Type*, *Test: Date*, *Test: 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 will be 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 (for example, *Test: AP - Subtype*). When referring to *Test: Date*, the combination of *Test: Date (month only)* and *Test: Date (year only)* will produce a date on the first of the month (for example, 12/01/2017). This concatenated date then behaves the same as *Test: Date*. #### 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*.