Identical email address limitation - anybody found a workaround?

Hi Liam,

Thanks for the reply. I can certainly see why in some/many/most instances identical emails would not be wanted or warranted and as you've pointed out can see how it can affect some of the system operations. But I'm still left with a problem I don't know how to resolve.

Many people use same email address?

Yes, in a club situation many people share the same email address, many couples and many families.

Lots of correct methods to implement such things in the proper way

relationships

I've looked into relationships but can't see the benefit. You don't seem to be able to run a report against them, so list all people with relationships, or filter against them. There is also no flag in the main customer details view that that customer has any relationships, so nothing to prompt you to look under "More>Relationships". You could add an extra CRM field with a note, but if you're going to do that, and with benefit issues raised above, you may as well just stick the relationships straight into the note.

custom fields

I am using custom fields, perhaps I could use them better, but however I use them I don't think they will resolve scenario 2.

use of username and password

How could U&P be used to resolve the issues presented in the scenarios?

Just a lot of the right way

I've spent a lot of time contemplating and trying to work out solutions to these issues. I think there are perhaps solutions around some of them, probably clunky ones and extra work for all involved, but I'd be willing to consider any reasonable solution. The one issue I can't see a solution for is scenario 2, just stumped on this one. Do you know what the system will do in this case? Will it produce an error message or will it accept the application and overwrite the existing record?

We're working on it, come up with a few possible workarounds... current favoured is the 'main' and 'attached' idea where we'll capture the main/primary details and take payment, then on 'thankyou' page if family or identical email has been detected we'll ask for 'attached' member details. Attached members will get a record but without an email address, which is not ideal, but is ok as they have agreed to be an attached member. Fair amount of fiddling and work involved.

Correction: 'senior' partners have not raised this as major concern. It's not on the radar so workarounds will be order of the day for foreseeable future.

Hello Deb and others with the same issue,

No, there is no suitable workaround for this issue. I was hoping that BC would at least allow a database check to see if the email address already exists, but BC tell me that can't be done. Which means worst case "Scenario 2" is a reality and has already happened on numerous occasions. And this means that you have to keep an eagle eye on everything and all records need to be manually checked for accuracy. This in turn means the automation is quite limited, which unfortunately defeats much of what we were aiming for.

There may be other ways of achieving all this on BC, but no one has to date shed any real light on such a solution--lots of 'yes you can...', but no real concrete methods outlined. Perhaps if we had a bigger budget we could have solved it? But then again maybe we wouldn't have, maybe the 'identical email issue' for this type of application is just a BC killer.

If you're looking to automate club membership I'd say look for another platform/solution. If you don't mind doing some manual checking and adjusting, then BC is probably an OK solution for the money.

Our solution in the end BTW was to have 'primary' and 'secondary' members. Both get their own DB record but only the primary member gets an email address. We created custom CRMs that gave us all the primary and secondary member info including a field where the secondary members are listed on the primary members record so you can see at a glance who belongs to who (again this has to be manually checked and changed when secondary members change). All active members are then subscribed to a secure zone, where the membership expiry date is set. If a membership lapses then that member is no longer active. Using secure zones we were able to get OK reports showing all active members. The automatic membership expiry email notices (anniversaries) at least work well, the anniversary date is set to the same as the membership expiry.

Hope this helps.

Deb, I think I've been around that mulburry bush... what you've just mentioned is why I thought it was acheivevible in BC in the first place... see my first paragraph of the initial post. I think BC should make it clearer in their literature that the YOUR ID will not override the email address.

BC support have stated that the system cannot currently allow identical email addresses for multiple customers even if you choose to use a unique YOUR ID. No identical email addresses can be used across multiple records, end of story.

If I'm worng on this, please post your solution.