Normally when we look up at a Raiser’s Edge constituent we use a variety of identifiers to find the specific record we are looking for. It may be that we are using biographical data such as surname, first name and parts of their address. To find a one unique record we need to search by unique identifier. The most obvious that we think of is the constituent Id. This is the most common unique Id available to us on the constituent search screen. Of course there is the national insurance number (also known as social security number in the US), and the membership Id (for those with the optional Membership module).
Behind the scenes there are two other Ids. There is the import Id. This is a unique Id for a record anywhere. It consists of your site Id combined with a unique Id for the record. If you export a record from your database and then try to import it into another organisations database (assuming that you are using the default generated import ids) there should never be a problem as your record is uniquely identified. The other id is rarely seen by the regular user but the system Id ties all the records together in the database.
When integrating The Raiser’s Edge with a third party application using a unique Id is a must. The alternative is to look up the constituent with imprecise biographical data. This may be necessary anyway to check for duplicate records. What are the advantages of the various sorts of Ids? The constituent Id is ubiquitous it is easy to find on the record and easy to search for a record with. However one major drawback is that it can be changed. This is perhaps not so obvious but it can happen. Using the Import Id or System Id has the advantage that it cannot be changed once created but they are also not so easily seen by the regular user.
Often a third party will have its own Id. It is possible to all the third party to determine the constituent Id on the record. One organisation that I worked with did not have constituent ids unless they had a gift. This was peculiar to their situation where gift processing was done in another system. If constituents did not have a gift they could not and should not be referenced in the other system.
When a third party has its own Id and no space to store the constituent Id storing the Id on the constituent record is a must. Many organisations will make use of the secondary Id (NIN, SocSec, etc). They change the name so it is more meaningful to their organisation and the third party applications they use. Some organisations will put these values in attributes or aliases. Attributes may seem like a good solution but in reality, unless there is a really good reason to attributes should be avoided for unique Ids. They are not easily search-able as aliases are. Aliases can be searched from the main constituent search screen whereas attributes can not. Clearly if a date or an extra comment needs to be attributed to the Id then attributes may be useful but otherwise aliases are a much better choice.
It is not necessarily just third party applications that have Ids to be stored in Raiser’s Edge. One organisation that I work with sells insurance (home, car, travel, pet, etc). They store the insurance policy numbers as an alias. When they get a query about a policy it is easy to bring up a constituent’s record based on their policy number.
How do you use Ids? How many do you have at your organisation? Where do you store them and what issues have you experienced with them? Let us know in the comments.
4 thoughts on “How many unique IDs should a Raiser’s Edge Consituent have?”
add in BBNC w/ User Networking Manager and there are 3 more IDs that get used.
We actually created a web method to convert them. Pass in an ID, it’s type and the ID that you need to convert it to and it spits back that ID.
One thing that’s been a bit exciting as we work with clients implementing our Raiser’s Edge importing tool is seeing email addresses becoming an almost-defacto ID. Yes it’s possible (even likely) for a constituent to have multiple email addresses or to change addresses, but at least 1) they are globally unique and 2) the constituent is likely to remember at least one of them. As online giving continues to grow, the fact that Import-O-Matic can use email addresses for matching constituents has been huge in helping organizations reduce duplicate constituent records. I am surprised that they have not updated RE7 to offer “email address” as a duplicate criteria.
I wonder if RE8 will include a tie-in for OpenID?
We’ve started using an attribute as an ID (data is from another company who have their own IDs which we need to record); one issue is that two (or more) constituents can have the same ID in the attribute value (there are already two constituents with the same ID).
With using aliases, my main interest would be in having them able to be used to store a unique ID, but that doesn’t seem possible.
Unless you write some kind of VBA script to check its uniqueness it would appear that the only fields where the value has to be unique are the constituent id and the social security/national insurance number. The import id could also be used but it is not as easily accessible and can only be added on import or via the API not through regular record creation.
Comments are closed.