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!

  • @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.

  • @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!

  • Dariel Dixon
    Dariel Dixon Community All-Star
    Seventh Anniversary Kudos 5 First Reply PowerUp Challenge #3 Gift Management

    @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.

  • Alex Wong
    Alex Wong Community All-Star
    Ninth Anniversary Kudos 5 Facilitator 3 bbcon 2025 Attendee Badge

    @Jana Viets
    You can check out some of the replies here, as it is related:

  • @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.

  • @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.

  • Karen Diener
    Karen Diener Community All-Star
    Tenth Anniversary Kudos 5 First Reply Name Dropper

    @Jana Viets:

    @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.

  • JoAnn Strommen
    JoAnn Strommen Community All-Star
    Tenth Anniversary Kudos 5 PowerUp Challenge: Product Update Briefing Feedback Task 3 2025 bbcon Attendee Badge

    @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.