How to find duplicate email address when update contact module in record.js?

Hi Nick Gamora

I'm afraid it is a polemic approach once, by implementing such a request, users may not be able to convert Leads. Are you sure about that?

Based on article you provided you need to customize the method _doValidateEmail in order to call a custom end point which would check for duplicates for a given email address which has not being saved yet.

Regards

Hello André Lopes.
I am confident in this task, we do not have converting leads into contacts, we create contacts directly by api, and there is a duplicate search. In my case, I want to prevent the presence of duplicate email addresses in the system when editing contacts.

Hello Nick Gamora,

did you come to a working solution for this?

I am debating if and how to include a validation that would ensure that we stop entering multiple contacts with the same email address.

In principle, I want email_addr_bean_rel to have only ONE row per email address for bean_module = 'Contact", so I can unequivocally identify a Contact by Email Address, which is something many Marketing and Financial platforms require.

Any lessons learned in your experience with this would be of interest to me.

Thanks,
FrancescaS

As Andre said, this is a polemic question. We have met similar requests quite often in different projects.

In my opinion, to block or not to block depends on the business-specific (who is a client, type and amount of data sources, and the possibility to change them, how many people are involved in the process, etc.).

When we designed the prospects' data collection processes for one of the banks, we had different validation logic for business and private customers. If a prospect was a regular private client, the CRM and front-end systems used hard validation (block entering such an address). But if it was a household or a business client, we used soft validation (inform the user) and don't block data entrance but initiate a special process to get the unique personal email.

The big challenge was to process data from the bank's website and a wide range of partners' systems that create data through API. We couldn't block data entrance and change their logic of work in most cases. To address this one, we added a specific stage of Lead processing, "Manual data validation." At this stage, e-mail addresses can be duplicated. Still, to move a Lead forward, it had to be defined type of client and, by necessity, recheck the e-mail address and other vital data.

An absolutely different solution was designed for VIP clients. For this type of client, adding e-mails or phones was possible in a pair with the type of questions only.

I hope it helps. If you have a specific question. I'll try to answer them :)

Regards,
Mykola

I was not thinking of limiting Prospects, or even Leads, just "Contacts" and the thought was to add an indication on Prospects and Leads that a "Contact" with that email address exists, this way when the person is processing the Prospect/Lead they can tell right away that this is a "returning Customer" and not a new one.

Good thoughts on the business/household vs individual though we make that distinction at the Account level, and a contact may be actively related to multiple Accounts, in our implementation.

I would think that one could still have a Lead Conversion process but have the process force the selection of the existing contact related to the lead's email address rather than presenting the end user with "Potential Duplicates" and "Ignore and Create".  Of course this would require a good degree of customization, but I think it's feasible. 

Alternatively one could prevent Lead Conversion altogether by simply adding a field that indicates that the Lead is an "Existing Contact" and simply link the Lead to the corresponding Contact by default (lead logic hook).

The user can still "work the Lead", but if an Opportunity needs to be created they can go to the corresponding Contact to work from there.

I see how it could be a controversial decision, but one that could be supported if the business rules permit such an approach.

Perhaps my view is simplified by the fact that we use Professional on-site, our leads are not linked directly to a Marketing platform (it's all custom) and we do not use Lead data directly for ROI calculations.