CiviCRM Community Forums (archive)

I have a common problem that I'm trying to figure out how to avoid. Let me explain with an example story...

• (1) We have a contact named "Marge Simpson" who has a contact record with very clean data. The record has two email addresses "marge@example.net" and "junk1234@example.com". As required by CiviCRM, each email address has a designated location, which doesn't really hold any meaning to us. Let's say that "marge@example.net" is marked as "home" and  "junk1234@example.com" is marked as "other". More importantly, from personal communication we know that she uses "marge@example.net" more reliably, so we have that one marked as primary.
• (2) We have an event registration form set up that includes a profile that includes a field for the contacts "home" email address
• (3) Marge uses the form to register for an event, and she writes in the email address "junk1234@example.com".
• (4) After she submits the form, we end up with two email addresses for her: a "home" email of "junk1234@example.com" and an "other" email of "junk1234@example.com". (We no longer have her "marge@example.net" email address.)

I have seen this data loss happen to our data and it frightens me.
How can I avoid it?

What I would expect CiviCRM to do:
For each piece of contact information gathered through a profile, Civi should check to see if that piece of information already exists on the user's record. If it does not already exist, then Civi inserts it in as an additional piece of information (not overwriting the information that is already there). This logic should apply to emails, phones, addresses, etc.

A more generalized frustration and concept for improvement:
In general, I'm disappointed by CiviCRM attachment to the idea of a "location" for contact information. As a user of the system, I really don't very often care what location someone's contact info represents -- I just want to be able to reliably store multiple pieces of information and reliably retrieve one or multiple pieces of information. The "location" field is sometimes helpful, but what would be more helpful would be fields like: a free-form "note" field, a "last-updated" field, a "status" field (with values like "valid", "invalid"), and a "bulk-contact" field (that could be set to true for multiple pieces of contact info). In my opinion, all of these fields could be reliably machine-processed and consolidated when duplicate pieces of contact information become present. For example, when Marge gives us an email address, we'd simply "de-dupe" all of Marge's email addresses... the email filed would get matched with an existing email, then that existing email would have all of the fields compared with the new email and the system would automatically decide which value takes precedence. I understand that my proposal above would require a significant amount of work to implement, but I feel that the current system has some pretty serious short-comings.

In general, I'm looking for some fundamental improvements to the way that we store and process pieces of contact information, but in the short-term I'm also looking for a work-around to avoid the data loss described above. How can I prevent that data loss?