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.