Time to play "Attribute or Constituent Code?"
We are looking to use RE as the primary CRM tool, and this means that we'll eventually take on even more groups. We want to narrow down our Constituent Code table so it's easy to use for segmenting communications and reports. Beyond that, is more detailed membership better tracked in Attributes?
We're thinking Constituent Codes equal Individual and Donor, then Attributes would show this person as a Legacy Society member, Board member, specific donor level, member of our Wellness facility, etc. Before making any sweeping changes, I need to make sure this is the most efficient way to go.
How do you segment?
Comments
-
I just went through that in a database I inherited that was a result of merging two separate RE databases. I pared down the Constituent Codes from over 100 to just under 20, and used Attributes to further identify the constituent. One example is Constituent Code = Trustee and Attribute "Trustee Type" is one of Trustee Emiritus, Honorary Trustee, Ex-Officio etc. (these were all formerly Constituent Codes)1
-
Hi Jennifer,
We use attributes to track a segmented giving society within our agency. For example we use the following:
Attribute Category: Name of Giving Society
Description (Table): Fiscal Year they were a member
Date: Date you added them to the giving society
Comments: Development Staff member who added them to the giving society
This Attribute is extremely helpful in helping us query upon the giving society and each specific fiscal year they were a member which all enable accurate retention and giving reports to be generated.
Hope this helps.
Barb0 -
Jennifer –
I’d suggest the following to consider (as an alternative to either an attribute or constituent code):
· Can you create your segmentations by using logic that already exists on the record?
o Ex: If your donor level is based on their giving history (gave $xxx dollars in the past xx years) you can get this group by criteria in a query.
o There’s really no value add to creating a separate coding system for this, and a separate coding system must be maintained. Over time, they may fall ‘out’ of the code definition and you then need to remove the code. And it’s often not possible to answer ‘who was in this donor level 10 years ago’ with a simple coding system.
· For membership in groups or boards, you can create a ‘fake’ organization record for the group and then add members using an individual relationship.
o Ex: We have an organization record for each of our boards, and maintain membership by creating individual relationships to the organization record.
o You can record a lot of information about the ‘membership’ on the relationship, and track multiple times when someone might be on or off the group.
o You can then create a query to get members of the group (everyone who has a relationship to ORG record and has the relationship type of ‘Member-Current’ (or however you set it up). And you can easily find out who was formerly or is currently in the group.
So in general, I think it’s better to try to use your data to create your groupings when possible. Constituent codes are best left high-level and as simple as possible. Additional codes (either extra constituent codes or attributes) are ‘tempting’ as they are seemingly easier to work with and use in queries. But additional coding on records always requires review and maintenance, and coding doesn’t work that well if you have situations where people will fall in and out of your groupings over time. So it may depend on the specific groups/segments you’re trying to capture and how long-term you need your data to be.
Gina Gerhard
Business Systems Analyst
New Hampshire Charitable Foundation
1 -
I went through this when I started. I inherited a database that had over 50 constituent codes. My belief is that constituent codes show how a person is generally associated with your organization. We use attributes to subdivide those generals into more specific details (e.g. constituent code = Parent; attribute = Current Undergrad Parent, Former Undergrad Parent, etc. or constituent Code = Alumni; attribute = Graduate School Graduate, Undergraduate Graduate, Withdrawn Alumni [12 units or more] etc.) Under Attributes, we have Type of Individual and Type of Organization.1
-
In keeping with the idea that the Constituent Code tells us how the record is related to our organization, we use a handful of primary constituent codes which are in ALL CAPS so they're easy to spot. The primary code is listed first and then their are some secondary codes not capitalized which help further define the connection i.e.
ALUMNUS
Alumni Associate
Alumni Bachelor
FRIEND
Current Staff
We also use quite a few attributes, and all of these are useful for querying and sorting the data.
I really LIKE Gina's suggestion (and I am totally stealing it) of creating "fake organizations" to help keep track of various boards, advisory groups and other groupings of folks.
Roger1 -
Question for Roger....
Not knowing your heirarchy, do you have 2 constituent codes for Alumnus, one capitalized and one not capitalized? In our case the Heirarchy is Trustee, Former Trustee, Alumni..... So in your scenario Trustee would always be in caps, but Alumni would have to 2 separate codes - one in caps and one in lower case. If they were a Trustee and an Alum, Trustee would be in caps and Alum would not, but if they were just an Alum, that would be in caps?0 -
It is really nice to have a manageable size list of constituent codes so having a plan and even re-evaluating it every few years is so key. When the list gets too big it really loses value. As others mentioned, we also have purpose for constituent codes of "why is this person/business in our database?" They have given great ideas/suggestions.
Another 2 cents to think about: this is just my view and I know the constituent code "individual" is used by many orgs. We do not use it as the fact that they are an 'individual' is already part of record as key indicator. Why duplicate data? And, the record is not in database because they are an individual - so we choose one of 3-4 other codes. We made this decision at conversion of our data to RE years ago actually at suggestion of BB staff we were working with. We've been quite happy with that decision.1 -
Like many others that commented, we try to limit the use of consituency codes but we do want the codes to be sufficient enough to describe the relationship the individual has with us. Likewise, our development officers like to see important relationships right away on PAGE ONE (that is the Bio 1 screen). Our constituency codes therefore include such things as: Board Member, Legacy Member, Hospital Executive, Giving Club Membership. However, we only include these codes on the record when the individaul is active and rather than end dating, we remove the constituency code when it no longer applies. We keep the historical information in attributes and we use attributes to further distinguish the relationship: ie: specific board membership with dates to/from in comments, specific legacy society membership, various committee memberships with dates to/from in comments etc.
0 -
JoAnn Strommen:
It is really nice to have a manageable size list of constituent codes so having a plan and even re-evaluating it every few years is so key. When the list gets too big it really loses value. As others mentioned, we also have purpose for constituent codes of "why is this person/business in our database?" They have given great ideas/suggestions.
Another 2 cents to think about: this is just my view and I know the constituent code "individual" is used by many orgs. We do not use it as the fact that they are an 'individual' is already part of record as key indicator. Why duplicate data? And, the record is not in database because they are an individual - so we choose one of 3-4 other codes. We made this decision at conversion of our data to RE years ago actually at suggestion of BB staff we were working with. We've been quite happy with that decision.JoAnn, I also hate the use of "individual" as constituent code, but have a system that has been using that for years. My dilemma is not really knowing what codes to use, especially if I don't know the constituent. I also hate the code "donor" as that can change often. What are the 3-4 codes you use? Prospect?
1 -
I will also suggest that you look at how RE handles constituent codes versus attributes in the database. For one, I find it easier to use certain mail functions with constituent codes rather than attributes.
I also find the use of "individual" to be redundant, but I find it useful as we export constiuent codes when reviewing reports and other data and it makes it easy to have individual, corp, foundation, etc all in the same place. I also use constituencies on the gifts for this same purpose. A board member's annual gifts may be coded board, but a small gift in honor of someone is coded individual. Youve gotta have individual onthe record to do that.0 -
Using a Constituent Code will let you easily run many canned reports by constituency for analysis of who is giving at what levels. Attributes don't have that easy ability. Constituent Codes will also let you track beginning and ending dates which Attributes can't do. Constituent Codes will automatically adjust heirarchy based on start and end dates (this is a double-edged sword). Mail setups can be easily filtered to include only selected Constituent Codes (I wish you could easily filter to EXCLUDE selected Codes, like "Board Member," which is a request at the Discovery suggestions site).1
-
RE Mail also allows you to easily include/exclude constituents from a mailing based on attributes. Although I agree thevworst part about attributes is that there are no to/from dates.
0 -
I have had to do this clean in several times. And let me say, walking in behind someone else's set up that is not explained and is not self-explanatory -- ugh. I would high suggest staying away for the Constit Codes called Individual and Organization, that is the equivalent of not using the Constit Code field at all, and is redundant.
One of my pet peeves is that the Constit Code does not have a 2ndary or sub code.
The Constituent Code should really the the relationship/affilation that record/donor/constituent has with your organization. Alumni, Board of Directors, Parents, Grandparents, Foundations, Business/Corporation, Educational Institution, Friend, Friend-Contact for Org
Because sometimes you need further explanation/filtering how their affilation I keep an Attribute with a drop-down that has those sub-categories like: This committee or That Society or Some Association or Board Pres Personal Friends/Colleagues. Then when you need to query or report you can go big picture or dial down a little more specific if needed. Has worked fabulously.
And as someone else mentioned the canned reporting works based Constituent not on Attributes the reporting is clean and quick when you need it to be something you don't want to export and re-work outside of RE.1 -
Just a comment on the remark about constituent codes not having a 'sub-code'.
- It's my understanding that's the distinction that RE offers between the 'primary' constituency code and additional constituency codes. The constituent code in the top position is considered by the system the primary one.
- In query and export they provide the ability to pull on ONLY the primary code, or all the codes. So in a sense, that serves as a sub-coding system.
- But I don't think in the filter tabs in mail and reports they offer this distinction?
1
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™
- 1 YourCause® from Blackbaud®
- 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
- 1.1K ARCHIVED FORUMS | Inactive and/or Completed EAPs
- 3 Blackbaud Staff Discussions
- 7.7K ARCHIVED FORUM CATEGORY [ID 304]
- 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