For me @Oshyan, this all seems like over-thinking something that’s really very simple.
A contact can have many email addresses.
That’s a one to many relationship.
I’m not sure why it needs to be more complex than that.
The benefits we receive from this structure are significant and I cannot see any downsides.
A customer emails us from their work email address. That arrives as a support ticket on their contact record. They then lodge another support ticket using a different email address. That arrives neatly as another support ticket on their same contact record. They then place an online order and use their spouses credit card and email address for invoicing purposes. The order arrives neatly on the same contact record. One of their team members orders from their point of sale system using a different email address yet again, it arrive neatly on their contact record.
As soon as a different email address is identified, it’s just updated and the issue of duplicate contacts is solved for the new email address from then onwards.
We have a Fibery report that lists duplicate contact by first and last name. This is checked weekly and all merges are completed. Once completed, it doesn’t need to be re-addressed unless a new email address is used by the contact and then it is solved once and only once.
We have a checkbox on the email database so we can mark as primary one of the email addresses.
We could also have more detail on the email address if we chose, but we don’t have the need right now. For example, we could add to the email database type, “Portal membership access granted”, “Used for billing purposes only”, “Team visible email address”, “Private” etc.
Even though we don’t need this additional information, because we’ve structure the database relationships based on the true statement, “A contact can have many email addresses,” all of these potential future uses are there and ready for us if/when they become required.
I have no idea why anyone would want to have multiple text fields on an entity with Email 1, Email 2, Email 3.
Our setup is elegant and solves a very real issue we’ve experienced in the past when dealing with CRMs. We would continually get duplicate contacts records, over and over again, when a contact would only have two different email addresses, with no way to solve the issue, as the CRM would allow 3 email addresses per contact record, but listed in text fields rather than via a one to many relationship as we have set up in Fibery. We could only set one email address as primary. The other email addresses were used for reference only. As soon as the contact used a second email address, it would create a duplicate contact record with that email address set to primary. We had two options. Either leave the duplicate contacts and have to continuously cross reference orders and communication between them (absolute madness) or merge the contacts, only to have continual duplicates created each time the user toggled between just two different email addresses.
Infusionsoft was one of the CRMs we’d used and this drove us crazy. From the very beginning in setting up Fibery a one to many relationship between contact and email for me was a no brainer. It was like the heavens had opened up.
In terms of the issue of being able to see just one field and then having the option of adding another, that’s exactly what our setup offers. There is just a single email address visible on the contact record. There are no empty fields. If I want to add another one, it’s a single click and the new field appears. We type the email address and create it and now there are two. We can add as many as we need.
I’m still not clear where the lack is in this. It’s Fibery magic. It’s a perfect solution for us.