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 please 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
  • Attach files
  • Kerry Meyers commented
    21 Mar, 2019 07:25pm

    Would you want to surface a message to a donor that they can identify themselves as related to but not the donor on the form?
    No, because adding complexity to the form may cause more abandonments, which means losing money.

    Or if they change the name information would you want the result to create a whole new record for the spouse and then link them together relationally?
    Yes, as long as we can catch it in the de-dupe report. Some records we will want to merge (e.g. spouses using the same email address and mailing address), and others we won’t. Although this may add more volume to our de-dupe process, it’s probably cheaper than adding complexity to our donation form.


    [Eagle302_874NoTag Small.jpg]

    Kerry Meyers
    Chief Development Officer
    Direct Marketing, Development
    T: 404-420-5190


    Waging Peace. Fighting Disease. Building Hope.
    A not-for-profit, nongovernmental organization, The Carter Center has helped to improve life for people in more than 80 countries by resolving conflicts; advancing democracy, human rights, and economic opportunity; preventing diseases; and improving mental health care. The Carter Center was founded in 1982 by former U.S. President Jimmy Carter and former First Lady Rosalynn Carter, in partnership with Emory University, to advance peace and health worldwide.

  • Guest commented
    21 Mar, 2019 05:37pm

    Ken, I appreciate the prompt feedback. The scenario that you put forward is not representative of how I experience this problem with LO though I do appreciate this challenge. My suggestion in this instance would be that only if e-mail + lastname+firstname is the same should we match to existing records otherwise a new record should be created.

    The way that I am experiencing this is interfacing RE 7.96 with LO. When I try to synch new RE constituents with LO my developer tells me that e-mail address is the only matching field that the LO API uses. The result is that when a spouse, family member, work colleague.... of an existing supporter comes in to our RE database, matching on e-mail address only will result in the new name overwriting the existing. Again, to my mind, it would be best to use a combination of e-mail+ lastname + firstname to match.

    Just to say too that we can't assume a spouse connection here. We just need to treat them as separate records.

    Hope this is helpful.

  • Ken Cantu commented
    21 Mar, 2019 04:04pm

    No features on the roadmap as of yet but it continues to be discussed. 

    Related I am talking about it internally this week at a high level with some folks as related to developing next gen donation forms. How would you expect this to work with autologins from emails? So if we had 1 of the two spouses in the database because they were the ones who have given before and we send an email to that person with a link to a donation form which is prepopulated with their information. Would you want to surface a message to a donor that they can identify themselves as related to but not the donor on the form? Or if they change the the name information would you want the result to create a whole new record for the spouse and then link them together relationally? 

    I'll take your input directly to this meeting to represent directionally where you would like to see this go. It's not a roadmap planning meeting but it would inform how we think about and plan to solve this better in the future. 



  • Guest commented
    21 Mar, 2019 03:47pm

    This issue was identified in May of 2015 and in March of 2019 we seem to be no further ahead as we are fighting with the same issues today.

    Has any change been made to address this issue?

  • Purdey Mak commented
    5 Feb, 2016 07:11pm

    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...

  • Ken Cantu commented
    14 Dec, 2015 10:00pm

    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!


  • Kerry Meyers commented
    14 Aug, 2015 08:32pm

    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,


  • Guest commented
    11 Jun, 2015 07:59pm

    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

    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)

  • Guest commented
    19 May, 2015 03:59am

    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.

  • Ken Cantu commented
    6 May, 2015 08:42pm

    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!


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