Your Raiser’s Edge™ constituent codes are the most basic, fundamental code for a record. This is the one code that should answer the question, "who is this person/organization and what is their relation to my nonprofit organization?" For years, I was a stickler about constituent codes and only would use seven distinct codes. Every record needed to fit into one of these seven strict codes. Then came NXT™, and I've since expanded my thinking. In NXT™, constituent codes have such prominent real estate that it's handy to have the codes front and center for anyone viewing the record. No longer are they stuck down at the bottom of Bio 1 like in database view. Fundraisers and leadership, who often prefer the NXT™ view, can quickly and easily understand who the person/organization is, their connection to the organization, and important information like if they are a board member, planned giving society member, or alumni. 

Why are constituent codes important?

Every record in your database should have a constituent code. This code should be assigned when the record is created and updated appropriately as the constituent's relationship evolves with your organization. Constituent codes are often used to segment understand who is giving. For example, in NXT™ under Reporting, there are pre-built dashboards that show gifts by constituent code and funds by constituent code (and others).  Constituent codes are also baked into many canned reports as a filter or as a segment option. This is why it is critical that every record have at least one code. We'll talk about what those codes should be (and shouldn't be) a little later! 

The order of your constituent codes matters when a constituent has more than one code. The constituent code listed first in the table should be the highest priority code. For example, if a constituent is a board member and a physician, board member should be listed first and be the primary code. It is important to note that the gift constituency code (on the Miscellaneous Tab of the gift record) will automatically choose the primary code. If you use the gift constituency in reporting (I'm a big fan of this!), you'll want to make sure that each gift has the right constituency. You'll see below that this constituent is a board member and physician. If the gift was their physician gift and not their annual board gift, you can choose the appropriate code. This is super helpful in reporting.

Using Date To and Date From

Here at Databasey, we clean up dozens of Raiser’s Edge™ databases each year, and one of the first items we tackle are constituent codes. It is surprising how many organizations do not use the Date To and Date From fields. Most organizations choose to build secondary codes with the word 'former.' Examples include Former Employee, Former Board Member, and Former Parent. The Date To and Date From fields are powerful functionality and can save you from creating duplicate codes for 'former.' I highly recommend that you use the date fields and not create shadow codes. 

Many of our clients have chosen to do 'former' because they have trouble querying for current Board Members or current Grandparents. But, once you get the hang of how to query using the Date To and Date From, you'll see how dynamic this functionality can be. When you want to pull a list of current constituents, you simply need to add the following criteria parameter to your query: Constituency Date To = Blank. That's it - easy breezy!

Using the Date To and Date From will also keep your constituent codes tidy and manageable. Another challenge we see with clients is that they don't track many dates. This is a great way to capture board service dates, employment dates with your organization, and any other engagement dates.

The Worst Constituent Codes

We've seen some doozies over the years, but essentially it all boils down to this: your constituent codes should be evergreen. The constituent code should be assigned once, and then the only update ever made to the code is Date To. Here are several examples of the worst constituent codes:

• Prospect/Non-Donor
• Monthly Donor
• Event Attendee
• Gift-in-Kind Donor
• Athletics Coach
• Major Gift Prospect

Do you see the issue with these constituent codes? Firstly, they need managing. If a constituent with the Prospect/Non-Donor code makes a gift, you'll have to remember to change the code. If a Monthly Donor, stops making a recurring gift, you'll have to go in and change the code. If the Major Gift Prospect turns out not to be a great prospect, you'll have to make the change. You shouldn't have to manage your constituent codes to this level of detail. That's why evergreen codes are important. Secondly, some of the codes above have data that should be stored in other places within Raiser’s Edge™.  Athletics Coach could be an attribute (it's not important enough to be a constituent code), and Monthly Donor and Gift-in-Kind Donor can be queried for by gift type.

My Perfect Raiser’s Edge™ Constituent Codes

Your constituent codes are important as they help fundraisers to understand who is giving and how their giving is changing over time. I use constituent codes in most of my dashboards and monthly reporting. Here are the foundational codes your database needs:

Depending upon the nature of your nonprofit, you may need additional constituent codes to properly categorize records. Here are a few that you might need:

• Physician
• Patient
• Faculty
• Student
• Alumni/ae
• Alumni Chapter
• Churches/Faith-Based Entities
• Parent
• Grandparent

I hope this gives you some food for thought as you consider your constituent codes. These are important codes that will help you categorize donors and understand who is giving to your organization. If your constituent codes are evergreen and answer the question, "who is this person/organization and what is their relation to my nonprofit organization?" you're in good shape!