Constituent Matching
 
 
 
You may wonder why in some instances a record is created when a record exists for a constituent interacting with your site, or you may wonder why a user of your site matched an existing constituent.  This document outlines the ways that constituents can be matched or created based on your site settings.
 
 
 
When a user interacts with Luminate Online while not logged in the system will perform checks to determine whether or not this constituent already exists in the system.  Based on the settings for your site the system will make a best guess as to whether the constituent performing the interaction matches a constituent that already exists.
 
The settings that will affect the match across the site are:
 
USER_ENFORCE_UNIQUE_EMAIL
 
Default value: TRUE
 
 
 
This setting means that if a visitor to the site uses an email address that matches an existing user, the interactions that the visitor performs will attach to the existing record.  If there are no records with the same exact email, the system will then check to see if the username field matches the email address.
 
 
If there happen to be more than one existing record with that email address the system will choose the earliest created record unless the name matches exactly with one of the records and not the other.  Then it will choose that record with the exact matching name.
 
CONS_MATCH_MULTIPLE_PRIMARY_EMAILS
 
Default value: FALSE
This setting will allow for the match to check for any previously used email addresses on a constituent record and match to that record.  There is list of every email address that a constituent has ever had on their record and even if the record has a new address, this will match the interactions to the existing record.  This will not change the email address on the constituent record.
 
DON_USE_NAME_MATCH_STRATEGY
Default value: FALSE
 
Enabling this setting means that if a user has the same exact name as an existing constituent but a different email address, this setting will attach any interactions of the user to the record with a matching name.  Should two records exist with the same name the older record is matched.  This setting will cause issues for common names (John Miller for example) where a record is incorrectly matched if the email address does not match an existing record but the name does.

The description of this setting's behavior can be found here - Donation Match Strategy Explanation
 
There are some settings that affect specific modules:
 
CAL_ENFORCE_UNIQUE_EMAIL
 
Default value: FALSE
 
 
 
This setting will override the site setting USER_ENFORCE_UNIQUE_EMAIL and allow duplicate emails to register for a Calendar Event.  This is useful for families and administrators registering several people under the same email address.
 
ECARD_ENFORCE_UNIQUE_EMAIL
 
Default value: BLANK
 
 
 
By default ECard module follows the site wide setting USER_ENFORCE_UNIQUE_EMAIL, but should it be set to TRUE or FALSE it will allow that behavior to override in the ECard module. (this is ECard Campaigns, not ECards on Donation Forms)
 
 
 
F2F_ENFORCE_UNIQUE_EMAIL
 
Default value: FALSE
 
 
 
This setting is FALSE to allow multiple people to register for the same TeamRaiser event with the same email address.  This is normally for families that share the same email address.
F2F_ENFORCE_UNIQUE_NAME_AND_EMAIL
 
Default value: TRUE
 
 
 
This setting enforces that you cannot register two constituents to the same TeamRaiser event with the same exact name (first and last) AND email address
TRIBUTES_ENFORCE_UNIQUE_EMAIL
 
Default value: FALSE
 
 
 
This setting is FALSE to allow multiple people to register for the same Personal Fundraising event with the same email address.  This is normally for families that share the same email address
TRIBUTES_ENFORCE_UNIQUE_NAME_AND_EMAIL
 
Default value: TRUE
 
 
 
This setting is FALSE to allow multiple people to register for the same Personal Fundraising event with the same email address.  This is normally for families that share the same email address
 
 
 
Here is an example situation where the site settings are:
 
 
 
USER_ENFORCE_UNIQUE_EMAIL: TRUE
 
DON_USE_NAME_MATCH_STRATEGY: FALSE
 
CONS_MATCH_MULTIPLE_PRIMARY_EMAILS: FALSE
 
 
 
Constituent 1 - Bill Jones, billyjones@gmail.com, Contact ID 1001001
 
Constituent 2 - William Jones, billyjones@gmail.com, Contact ID 1001002
 
Constituent 3 - Bill Jones, billyjones@gmail.com, Contact ID 1001003
 
 
 
A user comes in and enters their information into a Constituent Record Information question on a survey.  They enter:
 
 
 
First Name: Bill
 
Last Name: Jones
 
 
 
 
This will match Constituent 1, the oldest constituent with that email address.
 
 
 
If a Bill was a little more formal in his entry:
 
 
 
First Name: William
 
Last Name: Jones
 
 
 
 
The match will be Constituent 2.
 
 
 
Although the email matches multiple entries, it has an additional name match with the second entry.
 
 
 
 If he is feeling less formal:
 
 
 
First Name: Billy
Last Name: Jones
 
 
 
 
This will match Constituent 1, and depending on the settings of the Survey question could update the first name of the record to be Billy instead of Bill.
 
 
 
If he decides to use his alternate email:
 
 
 
First Name: Bill
 
Last Name: Jones
 
 
 
 
This will create a new constituent record.  NOTE however that if the setting “DON_USE_NAME_MATCH_STRATEGY” were set to TRUE, this would have matched the interaction with Constituent 1 with a matching name.  This would not ever update the email address, though the email address used would be in the Survey interaction.
 
 
 
 
 
 
 
Let’s try new settings:
 
 
 
USER_ENFORCE_UNIQUE_EMAIL: FALSE
DON_USE_NAME_MATCH_STRATEGY: TRUE
 
CONS_MATCH_MULTIPLE_PRIMARY_EMAILS: FALSE
 
 
 
Our user comes back to the site and fills out:
 
 
 
First Name: Bill
Last Name: Jones
 
 
 
 
This will match the first record, with a name and email match.
 
 
 
Let’s say he tries:
 
 
 
First Name: Will
Last Name: Jones
 
 
 
 
This creates a new constituent record.  The email matches, but there is no exact name match.
 
 
 
How does the CONS_MATCH_MULTIPLE_PRIMARY_EMAILS being set to TRUE work?
 
 
 
First Mr. Jones has to change his email address.  Let’s say he starts his history on your site with the email:
 
 
 
willyjones420@gmail.com, but decides to get a little more formal in his older years. He changes his email address to williamjones401K@gmail.com.  He doesn’t really interact with your site for many years but comes back and forgets to use his new email because all of his email still hits his old account.  Even though you can’t see the old email on his record, it will attach the interaction to his existing account, but will not update the email address back to his alternate address.
 
 
 
What if Mr. Jones had two accounts - one new one (added by the offline database perhaps) that had the old email address as the primary?  With the choice of a constituent with an email in history and one with the email as the primary current email, the system will choose the constituent with that address as the primary address.

Why isn't this set to TRUE by default?  There are instances where data is incorrectly updated on existing records such as a poorly done upload that changes constituent email addresses incorrectly.  If this occurs and the data is fixed, there may be instances of records being matched that have no evident relationship to each other.

If you ever need to know your site's current settings or if you would like to change the settings, please contact support.