When doing a Contact Import, have error message identify if an email is a duplicate email and already in use in the same import OR the email is already in use for an existing Contact in HubSpot.
This will prevent HubSpot from automatically NOT including the Contact on the import which is currently the process. The current process does not show which Contacts were not imported so the user has no easy way to flag the issue and make the change. This current process is called a silent delete.
Great suggestion! Better import validation and a clear error report for duplicate emails would improve data accuracy and the overall user experience.
The biggest issue is that skipped contacts aren’t clearly shown, so you may only notice later when someone is missing from a campaign.For now, I’d remove duplicate emails from the file before importing and compare the number of rows with the created and updated totals afterward. If the numbers don’t match, something was skipped. A simple report showing the skipped row and the reason would solve this.
@Liana_Preston I agree with you that a simple report on HS part is required or handle them inline on the import as errors just like other errors are handled on import. I don’t agree with having the user have to do a count after. The count only says there was an error and does not identify an error. Even with the best practices (i.e. check import before hand), mistakes can still occur if that was missed and it also does not handle duplicates that are already in HS.
+1, with one detail that I think matters for how the error report should be designed.
The two cases in the title behave differently and need different fixes, so a single
duplicate flag would not be enough.
Email already exists in the portal: usually this is intentional and the row is an
update. Treating it as an error would just add noise, but showing it as matched to an
existing contact would still be useful.
Same email twice inside the import file: this is the one that hurts. The rows do not
stay separate, they resolve into one record, so conflicting values across the two rows
get settled silently and you can end up with a contact that imported fine but carries
the lifecycle stage or owner from the wrong row. A row count catches a contact that is
missing. It does not catch a contact that is present with the wrong values.
Worth adding that in-file duplicates often do not look like duplicates in a spreadsheet.
alex@example.com and ALEX@example.com, or an address with a trailing space, sort as
different values and survive a sort and eyeball pass, but they collide at import time.
That is why cleaning the duplicates before importing is harder advice to follow than it
sounds.
What would actually fix this: the post import screen listing the affected source row
number, the email, and which of the two cases it was, in the same place the other import
errors already show up.
Thanks for building on this. I agree there needs to be something done for post import resolution process. This could also be the same for company records using a bit of AI. Since some companies use different domain names for both marketing purposes and updating their brand.
The company side has an extra wrinkle worth separating out. Contacts collide on one field, so a match is either right or wrong. Companies collide on a name that legitimately varies: Acme, Acme Ltd, Acme Limited, plus the rebrand case you mentioned where the domain itself changed.
That is a judgement call rather than a lookup, which is why I would want it surfaced for review rather than resolved automatically, whatever is doing the matching. The failure mode of a wrong auto-merge is worse than the failure mode of a queue: merged records are painful to unpick afterwards.