Constituency Codes: Hierarchy, End Dates & Attributes (Oh My!)
Hi all,
We are a fairly recent implementation (from Banner to RENXT) and we are continuing to refine our processes around constituency codes and trying to simplify things. We are a higher ed institution and our main constituency groups are: Alumni (3 sub categories), Employees (current and former), Organizations (various types), Board members (current and former) and Friends (reserved for those with no other relationship other than donations). So I have a few questions:
1) It seems as though there are problems with gift reporting if you use end dates on the constituency code itself (ie, gifts from that constituent that fall outside that active period will not be reported on as part of that group). We code employees and had thought to move to using an end date, but now realize that we may need to either keep our former employee constituency code type or create an attribute to code current and former with end dates. How do you manage relationships where there is a finite time period but any giving the person is doing is likely related to that relationship (whether current or former). Attributes? Constituency Codes?
2) Hierarchy of constituency codes - this is related mostly to the fact that insights designer only allows you to filter based on primary constituency code. So that hierarchy has to facilitate the most important reports you pull. For those of you who are higher ed - is Alumnus at the top of your constituency code hierarchy? How do you manage this? Also if you change the hierarchy - does that automatically change the primary constituency code on the constituent records or does that have to be recoded manually?
Any thoughts you might have related to these issues in general around constituency code management appreciated!
Miranda
We are a fairly recent implementation (from Banner to RENXT) and we are continuing to refine our processes around constituency codes and trying to simplify things. We are a higher ed institution and our main constituency groups are: Alumni (3 sub categories), Employees (current and former), Organizations (various types), Board members (current and former) and Friends (reserved for those with no other relationship other than donations). So I have a few questions:
1) It seems as though there are problems with gift reporting if you use end dates on the constituency code itself (ie, gifts from that constituent that fall outside that active period will not be reported on as part of that group). We code employees and had thought to move to using an end date, but now realize that we may need to either keep our former employee constituency code type or create an attribute to code current and former with end dates. How do you manage relationships where there is a finite time period but any giving the person is doing is likely related to that relationship (whether current or former). Attributes? Constituency Codes?
2) Hierarchy of constituency codes - this is related mostly to the fact that insights designer only allows you to filter based on primary constituency code. So that hierarchy has to facilitate the most important reports you pull. For those of you who are higher ed - is Alumnus at the top of your constituency code hierarchy? How do you manage this? Also if you change the hierarchy - does that automatically change the primary constituency code on the constituent records or does that have to be recoded manually?
Any thoughts you might have related to these issues in general around constituency code management appreciated!
Miranda
0
Comments
-
I think you're on the right track regarding your CCs. The first thing I would note is that it might be worth noting the relationship between primary CC and gift constituency. By default, the primary CC will be gift constituency, but it can be changed upon entry. It may be better to report on gift constituency if possible. There are times were a gift does not match up with the primary constituency.
If you use dates in your constituencies, you will have to remember to add that date in your queries. (for instance, constituency = alumnus & constituent date = 7/1/2020)
In regards to hierarchy, I think alumni is generally your primary code, but there are always exceptions. If you have a board member that is also an alumnus, I think you'll probably have the board CC as primary. All codes are coded manually, so it depends on the constituent record you are editing.0 -
HI Miranda,
I work in higher ed. In regard to your question regarding constituent codes and end dates. Here is an example of how we do it and it has worked well for us. Say John is a current board member and an alum. His hierarchy would look like this:
Board of Trustee (Current) with a start date of 11/21/1999
Alumni with a start date of 05/08/1988
When John's board term is up I would put an end date on his board of Trustee (current) entry, add a Board of Trustee (former) constituent code and a start date and move the alumni entry up in to the primary position. It would look like this:
Alumni (start date) of 5/8/1998
Board of Trustee (Former) with a start date of 10/01/2020
Board of Trustee (Current) (Start date) 11/21/1999 (End date) 09/30/2020
Because Alumni is now primary all the Gift Constituencies will now be under Alumni where before they were under Board of Trustee (Current). It allows a little more granular reporting.
At our institution Alumni is always primary unless the person is also a current board member or an employee and then those codes are primary until they term or employment ends.
Here is another example of a entry
Alumni (start date) 05/08/2020
Current Student (start date) 08/02/2016 (end date) 05/07/2020
Hope this helps and wasn't too confusing.
2 -
I do it the same way Lynnette Fisher does it.0
Categories
- All Categories
- 6 Blackbaud Community Help
- 209 bbcon®
- 1.4K Blackbaud Altru®
- 395 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 1.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- 15 donorCentrics®
- 360 Blackbaud eTapestry®
- 2.5K Blackbaud Financial Edge NXT®
- 648 Blackbaud Grantmaking™
- 567 Blackbaud Education Management Solutions for Higher Education
- 3.2K Blackbaud Education Management Solutions for K-12 Schools
- 937 Blackbaud Luminate Online® and Blackbaud TeamRaiser®
- 84 JustGiving® from Blackbaud®
- 6.5K Blackbaud Raiser's Edge NXT®
- 3.7K SKY Developer
- 247 ResearchPoint™
- 118 Blackbaud Tuition Management™
- 165 Organizational Best Practices
- 239 The Tap (Just for Fun)
- 33 Blackbaud Community Challenges
- 31 PowerUp Challenges
- 3 (Open) PowerUp Challenge: Data Health
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Product Update Briefing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports+
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Email Marketing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Gift Management
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Event Management
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Home Page
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Query
- 782 Community News
- 2.9K Jobs Board
- 53 Blackbaud SKY® Reporting Announcements
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)



