Constituent Coding for Giving Circles
Hello all – We have been trying to figure out the best way for coding constituents in two of our giving programs (monthly giving and mid-level giving). Currently, we are tracking it based on an attribute (using Description as a way to indicate status - Active, Lapsed, etc). Does anyone have any recommendations for tracking this that has worked for their organization? We are particularly interested in being able to track constituent status/participation in programs over time without having to rely on giving history directly. Thank you!
Comments
-
@Jana Viets, Hi Jana, We use a constituent code for monthly donors as well as major donors. I'm interested to hear responses on how others track mid-level donors. Thanks!
0 -
@Jana Viets
I've used the membership module for this before, but if you don't have that… perhaps set up the giving circle program as an org record and use relationships to it with the dates filled in? I wouldn't use a constituent code, but attributes could work out in my databases.1 -
@Jana Viets
I'm interested in this as well. We will be rolling out our Mid-Level Giving Club this fall (and are new to RENXT). There will be multiple levels within the MLGC so perhaps use the description of the MLGC attribute to indicate the specific level within the club. IDK-we're still looking at options. Thanks for this post!0 -
@Jana Viets In my experience, the membership module works well for this. Outside of that, attributes are the best way to go, as long as you have a plan for managing them (and the fact of there not being a good alternative to the membership module). I always discourage constituencies based on giving as that data is volatile and subject to change often.
4 -
1
-
@Jana Viets
I'm curious why you don't want to rely on giving history. This will always be the most accurate, and even past giving can change due to gift adjustments, or discovery that a gift was entered on a record incorrectly.Whenever I see organizations add extra information like this, it is never maintained carefully and is never correct. Plus is adds more work.
6 -
@Jana Viets
Totally agree with what @Karen Diener said. That way would add more work and its highly unlikely it will be mantained. I'm saying that out of experience, because we had just that situation. We now base it on giving, and therefor set up a process with Power Automate that calculates the sum of gifts and puts that data into an attribute. Since this happens every night, we always have reliable donor levels.2 -
@Karen Diener I appreciate the recommendation, however, we can't globally assign all donors based on giving history as we have people who opt out, or who on a case-by-case basis should not be coded to the giving program, even if their giving fits the set criteria.
0 -
@Karen Diener I appreciate the recommendation, however, we can't globally assign all donors based on giving history as we have people who opt out, or who on a case-by-case basis should not be coded to the giving program, even if their giving fits the set criteria.
That might be the part worth coding then - the exceptions. That way, you could query everyone who meets the giving criteria unless they have have one of the suppression codes.
If that would work, I think an Attribute may be best. The category could be a little more generic, like “Exclude from giving circle”. The descriptions could be the various reasons, like “donor opted out” or “staff opted out”. Then you still have dates and comments to add other data if needed.
That may not be the right construct exactly for the attribute, but I think I would much prefer coding it that way. Code the smaller set of people who are out, rather than the bigger set of people who are in.1 -
@Jana Viets Also agree with @Karen Diener. You must be coding the ones who opted out or making notes somewhere already. I'd go with an attribute/custom field with a table. So easy to query out or exclude using the attribute tab options in many reports.
0
Categories
- All Categories
- 6 Blackbaud Community Help
- 209 bbcon®
- 1.4K Blackbaud Altru®
- 394 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 1.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- 15 donorCentrics®
- 359 Blackbaud eTapestry®
- 2.5K Blackbaud Financial Edge NXT®
- 646 Blackbaud Grantmaking™
- 563 Blackbaud Education Management Solutions for Higher Education
- 3.2K Blackbaud Education Management Solutions for K-12 Schools
- 934 Blackbaud Luminate Online® and Blackbaud TeamRaiser®
- 84 JustGiving® from Blackbaud®
- 6.4K Blackbaud Raiser's Edge NXT®
- 3.7K SKY Developer
- 243 ResearchPoint™
- 118 Blackbaud Tuition Management™
- 165 Organizational Best Practices
- 238 The Tap (Just for Fun)
- 33 Blackbaud Community Challenges
- 28 PowerUp Challenges
- 3 (Open) 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
- 779 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)






