How many Constituent Codes do you assign to a single Constituent?
I've have realized the way we've set up our constituent codes, we either lose some historical information on our constituents, or we have to go around our elbows to get to our noses to export the information from RE.
For example:
We code our Alumnus who work for the university as a professor and is a parent of a current student as an ALUMNUS PARENT FACULTY.
Now, when the professor retires and/or the student graduates, the constituent in question switches back to just ALUMNUS - dropping both parent tag and faculty tag.
We have to query by relationship type to get previous parents or retired fac/staff, which can be overly complicated. For former Trustees/board members, we have a free text field in attributes that's almost impossible to query correctly on. Without continuing to go on and on, I'm seeing more and more issues with clean, accurate data.
All this to ask: What is your institutions best practice for constituent codes? How many do you assign? What do your procedures look like?
We're about to move to NXT in March and hoping I can convince my institution that it might be beneficial to use more than one constituent code moving forward. I'll take any advice/help I can get!
Thanks!
Comments
-
I would certainly think you could make a case for more than one code just looking at your example of alumnus faculty. The individual is in your db for two reasons: alumnus and faculty. Those are two separate relationships with differing from and to dates. Adding all that work to query former relationships can get very messy, very quickly.
Obviously you do not want a person to have unlimited constituent codes but if a code is a valid relationship reason for the record to be in database, IMO, it warrants a code. Having multiple codes to filter is so, so much easier, cleaner to query.
I would suggest you create a hierarchy of the constituent codes so you are consistent in which is the primary for records with multiple.10 -
I work at a K-12, and we do use more than one code per constituent where warranted. In your example, ours would be come Alumni, Parent of Alumni, Past Faculty. My org has elected not to use to/from dates on our constituent codes, but that information is contained in the relationship record so it has not caused us too much hassle.
I would also echo what JoAnn said - have a hierarchy for your codes. For us, a current Parent "outranks" an Alumni. Take a look at your fundraising initiatives and strategy, and be sure to document whatever your org ends up doing!2 -
As many as warranted. I use constituent codes as descriptors for how the constituent is related to us. So if they're an adopter (we're an animal shelter), they get an "adopter" code, but they may also be a volunteer, recurring monthly donor, gala attendee, and walk-a-thon participant. Those are all codes. Every month I go through a bunch of global changes that will add or remove codes based on whatever query parameters are associated with each.
Honestly there's so much overlap here that the codes are only rarely useful, so I may not be the best person to answer now that I think of it.2 -
We use the one constituent per record rule. If a person is an Alum and Med. Staff, their conscode is Med. Staff and their attribute of Secondary Affiliation is Alum. We also us an attribute of past affiliation; so if a Med. Staff leaves, his/her conscode would go to Alum and their Past Affiliation would become Med. Staff. We have differing variances for each situation. It allows our reporting and queries to be much cleaner.1
-
If I'm understanding this correctly LINDSEY COPELAND, you use one code per record, but also have multiple variations of that code for each combination of codes?
So instead of just having a parent code, you would have alum parent, Faculty parent, alum parent faculty, etc. Then I guess you still have just the parent code for those individuals who only have that relationship. That sounds like a difficult tedious process to navigate. I don't know what is gained by this structure. If you're using combination codes, your organization has already determined that individuals can have more than one constituency concurrently. Then why not use multiple codes, and make life a little easier. You are exchanging cleanliness in your records to a crowded constituency code table.
I agree with JoAnn Strommen, in that your hierarchy of codes should be the determining factor here. I definitely agree that you can get too crazy with constituent codes, but sometimes there's really no other way. I usually have to take a step back and think about how the codes will be used. Sometimes a constituent can have too many codes that they are included in everything, and/or excluded from nothing. But you'll know where the tipping point is for your organization.
5 -
We use to and from dates for ONLY 3 of our constituent codes: Board Member, Staff, Intern. This is especially helpful with the Board, because our board members are elected for a 3 year term, can run for a second term, and then after 6 years of service MUST take at least a year off. Then when they come back on that board term is added to their constituent code. Board Member out ranks all other constituent codes.
Our other constituent codes allow for as many as needed as other posters have mentioned, but the best practice is to have a hierarchy for those with multiple codes.
4 -
If one is a Board Member for a number of years and then is no longer on Board, do you add code of friend or donor so as not to remove them from data base?
1 -
Dariel Dixon:
If I'm understanding this correctly LINDSEY COPELAND, you use one code per record, but also have multiple variations of that code for each combination of codes?
So instead of just having a parent code, you would have alum parent, Faculty parent, alum parent faculty, etc. Then I guess you still have just the parent code for those individuals who only have that relationship. That sounds like a difficult tedious process to navigate. I don't know what is gained by this structure. If you're using combination codes, your organization has already determined that individuals can have more than one constituency concurrently. Then why not use multiple codes, and make life a little easier. You are exchanging cleanliness in your records to a crowded constituency code table.
I agree with JoAnn Strommen, in that your hierarchy of codes should be the determining factor here. I definitely agree that you can get too crazy with constituent codes, but sometimes there's really no other way. I usually have to take a step back and think about how the codes will be used. Sometimes a constituent can have too many codes that they are included in everything, and/or excluded from nothing. But you'll know where the tipping point is for your organization.
It is definitely tedious. At the end of every semester and the end of both calendar year/fiscal year, we have to run several queries to find those who have phased out of their current constituent code. For example: Alumnus parent whose student graduated in December shifts back to just an Alumnus. Although I believe our database to be pretty clean, the queries never catch everything and some manually follow-up always has to happen. Your feedback is right on the money. I inherited this system and all these comments are really useful in helping persuade my team it might be a good idea to try another way!
2 -
Maura Coppola:
If one is a Board Member for a number of years and then is no longer on Board, do you add code of friend or donor so as not to remove them from data base?
Maura Coppola - our board members have whatever constituent code is their affiliation to the university (Alumnus, Parent, Faculty, Friend, etc.). We use attributes to track board/council members. Unfortunately, the system was set up where dates of service are not tracked. It's manually added as a range in the COMMENTS field -- which is free text and nearly impossible to query.
1 -
We recently modified our coding and only use one code per constituent in order to more easily see where our gifts are coming from. We use education relationships to track info on parents, students, grandparents. The class year determines current student or alumni status (so we never have to change student status to alumni), and the parent/student/grandparent information is added in school type. We track board service under attributes with their start date listed. Their term is put in the comment section. Faculty and Staff are listed in an employee relationship to the institution "mothership", which is a constituent.1
-
I may be an outlier here as well, but in my experience I really prefer that constituent codes describe the constituent, who they are, rather than their relationship for us. For example: individual, corporation, church,foundation, etc. and then use attributes to describe their relationship to us, for example: board member, committee chair etc.
2 -
At my former organization (I'm a consultant now), we tried to keep it to no more than two or three codes per constituent, and they reflected the most important relationships with the college. We did use dates for Board members, but we changed them from Board to Former Board Member when they left, just so that regular lists were easy to pull. We had 30 or so different Constituent Codes, but the most I allowed after a huge clean-up was three: something like Alumni and Faculty/Staff was pretty common. We had Former Faculty/Staff as well - same deal as with the board. For people who didn't have any special relationship, we just used Individual or Organization, and then changed them later if desired. I did delete those generic ones when we added something useful. I'm not a fan of insisting on just one - the alumna who joined the staff is a perfect example: we want to include her in all the alumni related mailings, but exclude her from general fundraising letters because she was staff. Anything more granular went into Attributes.
Gracie Schild
Bluebird Business Services
Santa Fe NM1 -
We also use as many codes as warranted, but rely on a priority hierarchy to determine which code gets precedence. We use the codes to indicate what relationship the person or organization has to us, with the hierarchy based on what we would want to know first about that entity. For instance, someone in our organization could be coded as a Current Board Member, Donor, Volunteer, Adopter. We don't use constituent codes to indicate event participation - for that, we'd pull based on event attendance. We also don't use constituent codes to indicate monthly donors - we use attributes for that. Organizations rarely have more than one code, however - that tends to be defined as what type of organization they are - e.g. Corporation, Foundation, Community Group, School/Educational Institution.
Hope that helps.
best regards,
Katie3 -
Wanting to send a general thank you to everyone who commented. Every. Single. Comment. was very useful to me and helpful!
THANK YOU THANK YOU!!1 -
How do you set up a Hierarchy of Codes? Is it how the constituency code is listed or is there an area in RE that allows a hierarchy set up?
0 -
Unless something has changed that I'm not aware of, it's totally based on the order they are listed on the record.
While a hierarchy master with in REwould be nice it could be fairly complex for org who use multiples and multiples. We have a list of our hierarchy in our data entry procedures.
0
Categories
- All Categories
- Shannon parent
- shannon 2
- shannon 1
- 21 Advocacy DC Users Group
- 14 BBCRM PAG Discussions
- 89 High Education Program Advisory Group (HE PAG)
- 28 Luminate CRM DC Users Group
- 8 DC Luminate CRM Users Group
- Luminate PAG
- 5.9K Blackbaud Altru®
- 58 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 409 bbcon®
- 2.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- donorCentrics®
- 1.1K Blackbaud eTapestry®
- 2.8K Blackbaud Financial Edge NXT®
- 1.1K Blackbaud Grantmaking™
- 527 Education Management Solutions for Higher Education
- 1 JustGiving® from Blackbaud®
- 4.6K Education Management Solutions for K-12 Schools
- Blackbaud Luminate Online & Blackbaud TeamRaiser
- 16.4K Blackbaud Raiser's Edge NXT®
- 4.1K SKY Developer
- 547 ResearchPoint™
- 151 Blackbaud Tuition Management™
- 61 everydayhero
- 3 Campaign Ideas
- 58 General Discussion
- 115 Blackbaud ID
- 87 K-12 Blackbaud ID
- 6 Admin Console
- 949 Organizational Best Practices
- 353 The Tap (Just for Fun)
- 235 Blackbaud Community Feedback Forum
- 55 Admissions Event Management EAP
- 18 MobilePay Terminal + BBID Canada EAP
- 36 EAP for New Email Campaigns Experience in Blackbaud Luminate Online®
- 109 EAP for 360 Student Profile in Blackbaud Student Information System
- 41 EAP for Assessment Builder in Blackbaud Learning Management System™
- 9 Technical Preview for SKY API for Blackbaud CRM™ and Blackbaud Altru®
- 55 Community Advisory Group
- 46 Blackbaud Community Ideas
- 26 Blackbaud Community Challenges
- 7 Security Testing Forum
- 3 Blackbaud Staff Discussions
- 1 Blackbaud Partners Discussions
- 1 Blackbaud Giving Search™
- 35 EAP Student Assignment Details and Assignment Center
- 39 EAP Core - Roles and Tasks
- 59 Blackbaud Community All-Stars Discussions
- 20 Blackbaud Raiser's Edge NXT® Online Giving EAP
- Diocesan Blackbaud Raiser’s Edge NXT® User’s Group
- 2 Blackbaud Consultant’s Community
- 43 End of Term Grade Entry EAP
- 92 EAP for Query in Blackbaud Raiser's Edge NXT®
- 38 Standard Reports for Blackbaud Raiser's Edge NXT® EAP
- 12 Payments Assistant for Blackbaud Financial Edge NXT® EAP
- 6 Ask an All Star (Austen Brown)
- 8 Ask an All-Star Alex Wong (Blackbaud Raiser's Edge NXT®)
- 1 Ask an All-Star Alex Wong (Blackbaud Financial Edge NXT®)
- 6 Ask an All-Star (Christine Robertson)
- 21 Ask an Expert (Anthony Gallo)
- Blackbaud Francophone Group
- 22 Ask an Expert (David Springer)
- 4 Raiser's Edge NXT PowerUp Challenge #1 (Query)
- 6 Ask an All-Star Sunshine Reinken Watson and Carlene Johnson
- 4 Raiser's Edge NXT PowerUp Challenge: Events
- 14 Ask an All-Star (Elizabeth Johnson)
- 7 Ask an Expert (Stephen Churchill)
- 2025 ARCHIVED FORUM POSTS
- 322 ARCHIVED | Financial Edge® Tips and Tricks
- 164 ARCHIVED | Raiser's Edge® Blog
- 300 ARCHIVED | Raiser's Edge® Blog
- 441 ARCHIVED | Blackbaud Altru® Tips and Tricks
- 66 ARCHIVED | Blackbaud NetCommunity™ Blog
- 211 ARCHIVED | Blackbaud Target Analytics® Tips and Tricks
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- Luminate CRM DC Users Group
- 225 ARCHIVED | Blackbaud eTapestry® Tips and Tricks
- 1 Blackbaud eTapestry® Know How Blog
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)
- 1 Blackbaud K-12 Education Solutions™ Blog
- 280 ARCHIVED | Mixed Community Announcements
- 3 ARCHIVED | Blackbaud Corporations™ & Blackbaud Foundations™ Hosting Status
- 1 npEngage
- 24 ARCHIVED | K-12 Announcements
- 15 ARCHIVED | FIMS Host*Net Hosting Status
- 23 ARCHIVED | Blackbaud Outcomes & Online Applications (IGAM) Hosting Status
- 22 ARCHIVED | Blackbaud DonorCentral Hosting Status
- 14 ARCHIVED | Blackbaud Grantmaking™ UK Hosting Status
- 117 ARCHIVED | Blackbaud CRM™ and Blackbaud Internet Solutions™ Announcements
- 50 Blackbaud NetCommunity™ Blog
- 169 ARCHIVED | Blackbaud Grantmaking™ Tips and Tricks
- Advocacy DC Users Group
- 718 Community News
- Blackbaud Altru® Hosting Status
- 104 ARCHIVED | Member Spotlight
- 145 ARCHIVED | Hosting Blog
- 149 JustGiving® from Blackbaud® Blog
- 97 ARCHIVED | bbcon® Blogs
- 19 ARCHIVED | Blackbaud Luminate CRM™ Announcements
- 161 Luminate Advocacy News
- 187 Organizational Best Practices Blog
- 67 everydayhero Blog
- 52 Blackbaud SKY® Reporting Announcements
- 17 ARCHIVED | Blackbaud SKY® Reporting for K-12 Announcements
- 3 Luminate Online Product Advisory Group (LO PAG)
- 81 ARCHIVED | JustGiving® from Blackbaud® Tips and Tricks
- 1 ARCHIVED | K-12 Conference Blog
- Blackbaud Church Management™ Announcements
- ARCHIVED | Blackbaud Award Management™ and Blackbaud Stewardship Management™ Announcements
- 1 Blackbaud Peer-to-Peer Fundraising™, Powered by JustGiving® Blogs
- 39 Tips, Tricks, and Timesavers!
- 56 Blackbaud Church Management™ Resources
- 154 Blackbaud Church Management™ Announcements
- 1 ARCHIVED | Blackbaud Church Management™ Tips and Tricks
- 11 ARCHIVED | Blackbaud Higher Education Solutions™ Announcements
- 7 ARCHIVED | Blackbaud Guided Fundraising™ Blog
- 2 Blackbaud Fundraiser Performance Management™ Blog
- 9 Foundations Events and Content
- 14 ARCHIVED | Blog Posts
- 2 ARCHIVED | Blackbaud FIMS™ Announcement and Tips
- 59 Blackbaud Partner Announcements
- 10 ARCHIVED | Blackbaud Impact Edge™ EAP Blogs
- 1 Community Help Blogs
- Diocesan Blackbaud Raiser’s Edge NXT® Users' Group
- Blackbaud Consultant’s Community
- Blackbaud Francophone Group
- 1 BLOG ARCHIVE CATEGORY
- Blackbaud Community™ Discussions
- 8.3K Blackbaud Luminate Online® & Blackbaud TeamRaiser® Discussions
- 5.7K Jobs Board