If I'm understanding the situation correctly here, the contacts aren't being added to the group and instead you're getting errors for duplicate individual contacts (not the soft credit contacts). Looking at the Benevity template, it looks like the dedupe rule is Email is enuf (unique match). Do you get the same result with Email is enuf (first match)?

@Lars I'm not sure it this answers your question. We are getting duplicate individual contact errors. I don't know if we get the same result with Email is enuf (first match).

@Elbar53 Can you try it with Email is enuf (first match) to see if that resolves the problem? I believe the errors that you are seeing are the expected outcome if using unique match.

I'll give it a try with a smaller file and let you know how it goes.

@Lars I'm in the middle of the Benevity import. I'm still getting a lot of errors. I was able to resolve quite a few. Here is a link to the error page. I still have over 4,000 items importing, so that number will change.
https://civicrm.wikimedia.org/civicrm/search#/display/Import_4130/Import_4130?_status=ERROR

Thanks @Elbar53, having those error messages makes it clear what the issue is. So we have a bunch of "Multiple contact matches with employer connection" and one "Did not find exactly one Organization with the details". Will dig in.

Sometimes we don't have the Organization in Civi. I'll have to add it.

The "Did not find exactly one Organization with the details" problem should be fixed by T415295: Chariot import fails when there is no exact match found for organization name which is pending review and we should be able to deploy Monday. I'll look into the other one.

"Multiple contact matches with employer connection" means we have more than one contact who matches on first name, last name, email and employer. This is in our own code and unfortunately currently doesn't use the duplicate finding rule or the add to group functionality.

For this import, we don't have email, so we are just looking at first, last and employer. It looks like in most cases these would be true duplicates and we should just pick the first one (and add them to the group to be deduped), but I can imagine there might be more than one donor named Mike Smith who works at Google or something like that. I note we also have zip code for these donors. Would it make sense to also check for matches on zip code (specifically if it is the same or empty on the existing contact) and then just add to the first match if we still have more than one?

I think more aggressive merging would also help here, but that's another project.

I think it makes sense to match to the zip code when it's the same name and company. @MDemosWMF what do you think?

Agreed! I think matching the zip would help as it seems that is more commonly included in the donor info. @Lars

The import is complete. There are 47 errors. Let me know when you want me to try importing them again.

Sounds good, zip code it is. This will take at least a few days to change on our end, but I'll let you know.
If we can't wait for that long, I can make a spreadsheet today with links to dedupe each of the duplicate pairs in the import errors, so you could just open up each pair and merge them.

@MDemosWMF are we ok to wait until next week? It will take a long time to merge each one.

@Elbar53 you can relay the information to Caitlin/Evelyn and see what they say as far as urgency.

@Lars Will we be able to import the Benevity errors soon?

Change #1242446 had a related patch set uploaded (by Lars SG; author: Lars SG):

[wikimedia/fundraising/crm@master] Improve individual matching for imports

https://gerrit.wikimedia.org/r/1242446

Change #1242446 merged by Eileen:

[wikimedia/fundraising/crm@master] Improve individual matching for imports

https://gerrit.wikimedia.org/r/1242446

@Elbar53 @MDemosWMF At long last, this has been fixed!

That's great news @Lars !