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

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

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.