search

SalesforceFoundation / NPSP

The current version of the Salesforce.org Nonprofit Success Pack
http://www.salesforce.org/nonprofit/nonprofit-success-pack/
BSD 3-Clause "New" or "Revised" License
16 stars 3 forks source link

BDI: If External ID is selected in import config, matching is not falling back to Contact Matching Rule as expected if Contact has External ID #5013

Closed judisohn closed 2 years ago

judisohn commented 4 years ago

Hub thread. Thanks again @davidhabib!

This was replicated in a scratch org with Advanced Mapping and Customizable Rollups enabled, just to make sure it's current.

Summary

The original intention of the External ID matching (it was the original developer who raised the issue) was that if a match is not found based on External ID, then the Contact Matching Rule selected would be evaluated and matched if appropriate. The current behavior is that if External ID is selected in the configuration and the DI record does not have the same External ID as on the Contact record, the selected matching rule is not considered. This will cause invalid and unnecessary record duplication for any rows that do not have the External ID populated.

Steps to Repeat

  1. Create custom External ID field on Contact and mark it External (text).
  2. Create custom Contact1 External ID and Contact2 External ID fields on NPSP Data Import object (text).
  3. Use Advanced Mapping to map the new NPSP Data Import fields to Contact1 and Contact2 groups, respectively.
  4. Create a Data Import record for First Name = First1 Last Name = Last1 and External ID = 1
  5. Process with the External ID as the Unique ID and First Name and Last Name matching.

image

The Contact is correctly created with External ID populated in the custom field. This is expected.

  1. Now, create another DI record. First Name = First1 Last Name = Last1 and leave External ID blank.
  2. Process with the same configuration as above.

Expected Result

The Contact should be matched to the previous Contact.

Actual Result

A new Contact is created.

The Unique ID matching was meant to be in addition to the Contact Matching Rule, not exclusive if selected.

judisohn commented 4 years ago

**lurch: add

davidhabib commented 4 years ago

thanks @judisohn. one small correction. I don't think it is totally ignoring the Contact Matching rule. So for example if neither the existing Contact nor the Data Import record have an externalId specified, the name matching will work. It's just when the existing Contact as an exernalId saved, but the Data Import record has null for the externalId. then it should still match based of Firstname Lastname (assuming that's the contact rule), but it does not match.

LurchTheButler commented 4 years ago

Tracking W-039035

judisohn commented 4 years ago

@davidhabib I tweaked it to make that point clear. Thanks.

LyallShank commented 4 years ago

It seems to me one of the main purposes of adding an External ID matching rule would be to protect contacts with External IDs from getting false positive matches from Name Matching alone. Another potentially valid use case would be to match by name if the existing contact didn't have an External ID and update the ID (Scenario 1) but never match with out the External ID when the Contact has an External ID (Scenario 2). @davidhabib, @judisohn. The way its working might be best. It avoids the false match potential in both scenarios.

mbeaty-sf commented 3 years ago

W-7781124

kporray1 commented 2 years ago

Please follow this Known Issue in the Trailblazer Community for updates.