You need to sign in to do that
Don't have an account?

De-Duping info within SF.com
We have an issue with duplicates in SF.com, primarily with leads & contacts. For those of you that purchase big lists and mail to them (in which case some of the names you purchase MAY already be in SF.com as leads or contacts), how do you go about getting that information into SF.com without creating tons of duplicates?
Does anyone else have an issue with the way the Leads module is set up?
THanks,
Brian
Brian,
Here's another area where I can help out :)
Regards,
Mark Williamson
I faced this problem with my own product. The answer (if there is one) stems from the question - What characteristics/properties define uniqueness? The API should not and does not dictate an answer. I used a canonical email address form. Sfdc requires this to be smtp - naturally. For Exchange addresses, I had to obtain the smtp proxy. For all smtp addresses, you have to make sure they're in the short form. There are two obvious flaws with this - email address are volatile (when the individual changes jobs) and mailing lists. Still, this seems better than any other approach.
WRT an automated way to remove duplicates, I don't know of any such tool, but my knowledge of the sfdc tools is pretty limited. Others could probably give a better answer. That notwithstanding, it wouldn't be too hard to write a program to do this. In fact, the coding is the easy part. The hard part is deciding upon the heuristics to apply.
Duke
My efforts to de-dup have used names and emails, I also look at the contacts' account heir, that is: if I find a duplicate name at a child account and a parent account then they are probably the same person.
I then move one of the contacts to the parent so they are at the same account, then construct a simple URL which places both of these names into the contact merge wizard.
I send a sheet of these links to our admin who can click, review the differences, and merge them (2 clicks)
This is still manual process for the admin ( I generate the links automaticaly) but it is mostly working.
We've got some pretty interesting issues in this area too. We are importing data from one source that looks like this:
Bob Jones, bob@jones.com
... and from another source that looks like this:
Bob Jones, bob@jones.com, Jones Corp
These are imported as *different* contacts, I assume because the account name is different? It seems a little crazy to me that SF doesn't use the email address as an indicator of duplication (or provide an option to enable it to do that).
It looks to me the only solution would be to pay the hefty costs of Enterprise and write some code to sort this out. I don't see any features in SF itself to handle this, and our data sources aren't very amenable to being merged before importing (this is a regular import, not a one-off).
Any clues?
Ollie
Brian;
On the account duplicate side you can try out our account de-duplication tool. It's still in beta and if you want to test out the beta you'll be able to use it till the end of March.
We're working on our Contact de-duplication tool and that will allow dupes to be found based on name, fuzzy name, email, last name, etc.
I've found that the only way to limit the creation of dupes from lead forms is to write your own and backend it via the API. That way you can limit the creation of dupes based on your own specific criterial.
Cheers;
GlennW - glenn.wilson@quotegen.com
I am interested in doing something similar.