Welcome to Luminate Ideas!

Please submit all product enhancement ideas below. We welcome your feedback; your ideas will be reviewed by the Product Manager that oversees the development of that part of the product on an ongoing basis and updated with its current status monthly based on our product planning process. Ideas you submit could help us shape features currently in development or grow our repository of requirements for our next big enhancement. Thank you for taking the time to share your thoughts and expertise with us.

If you believe you are experiencing a defect or have general information that you wish to publish, please submit those within the Luminate Community or contact Support.

Address single email for two people

A donor and his wife, with the same email address, both make donations online, at different times. The challenge is that LO doesn’t know the difference between them because it is looking exclusively at email address and would use the email to match to an existing record, updating all of the fields for the donor and essentially overwriting the spouses identity.  Is there anything they could consider or that we might recommend to address this challenge on either side of Luminate?

On the LO side, it would be awesome if we could have it built to recognize same email but different name at entry. If the name was different then create a new record or create a “this looks like something a person should see” purgatory so it can be managed by an admin. I wasn’t sure if anything like this was already in the general plan for the purposes of building householding across platform, which I thought was still in the works.

  • Guest
  • May 6 2015
  • Reviewed: Voting Open
Area of the Product Donations
Org/Company Name
  • Attach files
  • Admin
    Ken Cantu commented
    May 06, 2015 20:42

    This is the default because Luminate is an email marketing system designed around the idea that 1 email = 1 person/target which is the most accurate and industry standard way of uniquely identifying users online. Optimally I think we want the system to continue to work this way because you can more accurately target end users with personalized messaging because your data on their interactions is tied to that one static value which is their email address. 

    However, with that being said, I know it comes up that some constituents do share one email account so I am interested in hearing from our users how they might expect a system which allows end users to share email addresses would work. There may be ideas and ways of doing this we can incorporate which we haven't thought of.

    Thanks for submitting your idea!

    Ken

  • Guest commented
    May 19, 2015 03:59

    Maybe it could be something along the lines of the household concept. Like there could be a shared household email option and at entry the system would evaluate on email and first name. If it was the same email but a different first name, it would create a separate contact on the household. If it was the same email and same first name, it would update the record. If it could be something a client could opt into or not - using a shared household email. If there was a household email in place it could be used to send a single email with multiple names. I'd be happy to connect you to the client that presented this challenge (UUSC) for any further discovery insights.

  • Matt Lindsay commented
    June 11, 2015 19:59

    Its my understanding there is a site option that can be updated to allow for different users to "share" an email address. Its not a site option a client can set.

    Ask about this Site Option / SDP
    USER_ENFORCE_UNIQUE_EMAIL

    However, there is some risk associated with making this change. But we have seen this make Duplicate Management a challenge and I can't fully recommend it.

    So those types of transactions don't go to Duplicate Management for the client?

    Other related Site Options

    CAL_ENFORCE_UNIQUE_EMAIL: FALSE (Calendar Event registrations, recommendation: FALSE)

    ECARD_ENFORCE_UNIQUE_EMAIL: FALSE (E-Card registrations, recommendation: same as USER_ENFORCE_UNIQUE_EMAIL)

    F2F_ENFORCE_UNIQUE_EMAIL: FALSE (TeamRaiser registrations, recommendation: keep FALSE)

    TRIBUTES_ENFORCE_UNIQUE_EMAIL: FALSE (Personal Fundraising registrations, recommendation: FALSE)

  • Kerry Meyers commented
    August 14, 2015 20:32

    I'm an experienced CLO client and this is the way I would handle this:

    1. Make two records (one for the wife, one for the husband) in your CRM (in our case it's Raiser's Edge). Link the two records as a spouse relationship. Both records will have the same email.

    2. In Convio, do the same thing. Enter those two records separately. One unique ID for the wife and another unique ID for the husband. Both records will have the same email though. Email duplication across separate records is possible in CLO.

     

    Just remember CLO is not intended to be a full-fledged CRM solution and it'll save you frustration.

    Good luck,

    Kerry

  • Admin
    Ken Cantu commented
    December 14, 2015 22:00

    Thanks for everyones input here. I'll pass along to the PM who is working on this for next gen and they may follow up with additional questions!

    Ken

  • Purdey Mak commented
    February 05, 2016 19:11

    yes, we have the exact same problem with a wife and husband making diff donations, using diff credit cards but the donation transaction gets recording to the husband's constituent record because they didn't bother to log out. We also had another problem before with multiple donations made by different individuals (all with different addresses and credit card info) all went into the same constituent record because he was not logged out. I'm wondering how to eliminate problems like this from happening? what's the best practice for the rest of the organizations that's facing this problem too? it's either having many duplicates or getting transaction records into the wrong constituent...

Privacy Policy | Safe Harbor Notice | Terms of Use | Acceptable Use Policy | © 2016 Blackbaud, Inc. All Rights Reserved