Best Practice: Constituency Codes

Shauna Kipper 2 · July 2019

I am doing a major cleanup of our Constituent Codes and my goal is to have minimal codes and properly use the Date to/from fields. Wondering what others' best practice is when entering constituency codes? Do you have many? few?

And, if someone "leaves" your organization and then returns, do you duplicate the constituency code with new dates or do you just modify the date and ignore the time they were away?

Thanks.

Dariel Dixon 2 · July 2019

I'm not a big fan of dates on constituency codes, because of the way they function in query. I also think duplicating codes is a bad practice for the same reason. I am a fan of having a minimal number of codes, but minimal is relative. There's always attributes for things that don't function as expected with constituency codes.

Shauna Kipper 2 · July 2019

Thanks Dariel.

I don't like attributes as I find they are a dumping ground for nonsense that should be placed somewhere else. That being said, I do have information all over the place and try to utilize every field I can.

I am being asked to report/track how our funds are being collected based on constituency code (we are a school, so Parent, Alumni, Board Member, etc.) There is a report that I have been using, but 'garbage in, garbage out' as they say. How would you track this without using cons codes?

Karen Stuhlfeier · July 2019

I'm with Dariel. We don't date constituency codes. Constituents change codes. For instance: Current Trustee's becomes Former Trustee's and Current Parents become Parents of Alums. If you date them there's always the chance that someone won't remember to add the dates. We have as few codes as possible and also use attributes for more granular information.

Karen Stuhlfeier · July 2019

I got rid of all of our meaningless attributes and only use them if they make sense.

Dariel Dixon 2 · July 2019

I think codes like Parent, Alumni, etc. are fine. and like Karen Stuhlfeier‍ mentioned, there are times when you'll need former and past iterations of codes. As long as you can keep that number down to a manageable level, I think you'll be fine. I've seen it stated that board membership and employee status can be measured by the membership module and the business relationships, but I also think that's a personal preference based off your reporting.

In regards to attributes being a dumping ground...well, that can be resolved with education and training. Having a crazy number of attributes is not unusual, but they are there to store things that don't fit in other places.

I stick to the rule of wide constituencies, and use attributes for fine tuning. Also, attributes are definitely more versatile that CCs, so there's that.

Karen Stuhlfeier · July 2019

Yes, with attributes you can configure them however you want. You can use tables, text fields, dates numbers - whatever works best for them. We use Past and Former constituent codes because that information plays a big part in our annual appeal and how we report on it.

Mark Guncheon 2 · July 2019

The fewer the Constituency Codes the better. We use attributes for more detail and while there may be too many of them, when I pull a query/report/export, I'm usually filtering for a particular one so that doesn't matter. We use from and to dates because it makes the CC more accurate. If someone is a board member and leaves, the become a former board member. The board CC is replaced by former board member with a to date. But a note is added to the record explaining the change. We tend to add notes whenever changes are made to a record so RE users can understand better why and who made changes. And if someone forgets to add a from date when adding a CC, if they've left a note, the date can be found and added. But it's important to place the most important CC in row 1 of your CC section.

Dariel Dixon 2 · July 2019

Mark Guncheon:
But it's important to place the most important CC in row 1 of your CC section.

I can't stress this enough. Especially with how they work with gift constituencies, and particularly how they act in NXT. Having a hierarchy of constituencies is so important, because people will have multiple constituencies at the same time.

Shauna Kipper 2 · July 2019

Thank you all for your help. I am overwhelmed with options. I didn't really think about "archiving" into attributes to add more information until now. I am going to try that and see how it goes. Wish me luck! Thanks again...

John Heizer · July 2019

We do use dates because I want to know which years that person was on the board so if needed I can go back and look at board giving 10 years ago. I can't do that without dates.

Deb Dressely · July 2019

We used constituency codes to indicate current board or former board and then used attributes to identify which board you served on (we had several hospital boards) and with attributes you have the ability to use both dates and comments.

Christine Cooke 2 · July 2019

I have found, working in school settings for 20 years (eek!) that you are always asked to report based on affiliation to your org. So yes, Board of Trustees/Regents Current/Former, Parents Current/Former, Alumni/Current Student, Grandparents, along with some other things. I am happy to share the list of Constit Codes that has ended up being used time and again every time I've move to a new school.

I also agree on the date business, because you have Codes that change every fiscal year. Board members goes from Current to Former, Students become Alums, Current Parents of those students become Parents of Alum (unless they still have another child enrolled, then that Code waits until the last one graduates/leaves). The Constit Date affect every report and query and can really muddy up the works in that regard.

If you do have certain affiliations where you really need to record the dates. Oftentimes that refers to Board members, you want their history, especially if they have stepped off and back on, plus they change roles within the group, that's where the Relationship tab is handy. Give them a relationship to your school and use the Position field to describe their role, the dates From and To and the Relationship/Reciprocal.

And! Remember to establish your org's hierarchy of Constituent Codes so that when reporting you have data that you can pull by any of their Codes or just their Primary Code.

John Heizer · July 2019

Christine Cooke‍ the problem with tracking such dates via Relationships instead of Constituency is that reporting on Relationship dates is even more screwed up and in flux (recent changes depending on which Patch you have installed). You can follow it on this thread: https://community.blackbaud.com/forums/viewtopic/151/40714?post_id=159637#p159637

Shauna Kipper 2 · July 2019

During my cleanup, I have found something interesting that might hurt me or help me.

I currently have, among others, up to three constituent codes on a single record for anyone who has been/will be a "parent".

1) Current Parent 2019-2020 (with date from AND to populated),

2) Parent (with date from populated, date to populated only if they are no longer a parent)

3) Past Parent (with date from AND to populated)

I pulled my report to see what it looks like and because it took the data based on my hierarchy and by the gift date AND because I have utilized the cons code dates, I am able to see what the constituent was at the time they made the gift. (e.g. a parent who made a gift who is STILL a parent, a parent who made a gift as a parent but is no longer a parent or a donor who made a gift while they were already a past parent)

If I were to change/update cons codes it would be an ever moving target.

Thoughts?

Christine Cooke 2 · July 2019

John Heizer:
Christine Cooke‍ the problem with tracking such dates via Relationships instead of Constituency is that reporting on Relationship dates is even more screwed up and in flux (recent changes depending on which Patch you have installed). You can follow it on this thread: https://community.blackbaud.com/forums/viewtopic/151/40714?post_id=159637#p159637

I understand that. I am talking specifically about a school setting. The standard reporting that Development/Advancement is asked for is based on the group/Constit Code. Reporting is based on Either the Constituent Code and Gift Date(s) or Gift Constituent Code and Gift Date(s). The Constit Code From and To Dates are not helpful.

Joanne McConnell · July 2019

Dariel Dixon:

I'm not a big fan of dates on constituency codes, because of the way they function in query. I also think duplicating codes is a bad practice for the same reason. I am a fan of having a minimal number of codes, but minimal is relative. There's always attributes for things that don't function as expected with constituency codes.

Joanne McConnell · July 2019

John Heizer:

We do use dates because I want to know which years that person was on the board so if needed I can go back and look at board giving 10 years ago. I can't do that without dates.

Sunshine Reinken Watson · July 2019

Chiming in on the date issue: I always use dates and find that it is a good record of when a constituent became involved in a specific way. Queries are not an issue, as I always include the "to" date.That said, in the interest of keeping the number of constituent codes to a minimum, I would just delete the date to when a constituent comes back to the organization unless the gap was significant or you need to report on that gap.

Mary Chase 3 · July 2019

I'm in the process of adding all "from" and "to" dates for all our trustee constituency codes. I think this is necessary if you want to run comparison reports, for instance a comparison of trustee giving over the last 5 years, let's say. If you don't add end dates but instead use only codes such as "former trustee", then whoever is coded as a former trustee but has gifts during the specified time frames and at the time the report is run would show up in whatever year they gave - regardless of whether they were on the board at the time or not. Not sure if I'm making sense....

Mercedes McCayRead · July 2019

I also am in the process of cleaning up constituency codes. I'm deleting those that are unnecessary/unhelpful, such as Capital Campaign Donor. I can easily find that out based on someone's giving. I am adding dates for the remaining codes because I think it's appropriate for those things I'm actually tracking. I work for a hospital foundation so my constituent codes consist of things such as Physician, Employee, Foundation Board Member, etc. For employees when they leave I actually track additional information under attributes, but using the constituent codes with dates seems to be the easiest way I've found to pull lists...plus all of the dashboards I've seen in NXT use them in their pie charts and I'd like those to be more valuable to my director at a glance.

Monica Dwight 2 · July 2019

Hello I'm Monica Dwight and I am responsible for cleaning up our Const. Codes as well. If anyone like to share a few of their hierarchy practices; I'd appreciate and welcome all suggestions. I need to gather a few org practices to better explain different structures so that we can use the best of all worlds. Thank you.

Dariel Dixon 2 · July 2019

Mercedes McCayRead:

I also am in the process of cleaning up constituency codes. I'm deleting those that are unnecessary/unhelpful, such as Capital Campaign Donor. I can easily find that out based on someone's giving. I am adding dates for the remaining codes because I think it's appropriate for those things I'm actually tracking. I work for a hospital foundation so my constituent codes consist of things such as Physician, Employee, Foundation Board Member, etc. For employees when they leave I actually track additional information under attributes, but using the constituent codes with dates seems to be the easiest way I've found to pull lists...plus all of the dashboards I've seen in NXT use them in their pie charts and I'd like those to be more valuable to my director at a glance.

I've found that many of the pie charts don't look at the constituency on the record, but rather gift constituency, which by default pulls in the primary constituency. I think that sometimes gift constituency is a better field than constituency on a record for some information.

Marguerite Gravois · July 2019

Has anyone developed a system to manage constituent codes after having ConnectRE activated? This is a whole new challenge.

Juanita Giles · April 2020

We are having a huge issue with Constituency Codes. When use REConnect, it overwrites the dates, even tho the code was already there. RE Connect seems to randomly update things in our database and overwrite information. The support people have been working on this for a few years!!!!!! Anyone else having issues with RE Connect?

Gina Smith 2 · April 2020

The only dates I see being entered so far are when a student enrolls or withdraws - student, parent and grandparent record cc's are being updated. They are being updated according to the Connect RE plugin set up choice (only choices right now are "last day of fiscal year" or "last day of academic year.") I go into the record after the update and change the current code "date to" to be the actual withdraw date for the student. The new "past" code that is added enters the "date from" as the process day - so if I processed it on a later date than the actual withdrawal date, I clean that up and change it to the actual withdraw date.

I haven't seen any other dates being overwritten. Is this happening when you link the records, or after the records are linked and updating records. I'd be curious to know if you see any patterns, so I can check my records to see if there are any changes like this that I've missed.

Madeleine Holdsworth · April 2020

We did a major overhaul of constituency codes; less is definitely more. I echo the sentiment about not using dates; I seem to recall when I redid our codes there was something in the knowledgebase indicating that using dates on constituency codes can muck up reports. You can always establish a relationship which includes the dates. We have a code of trustee for our board members, but we also include their relationship to our board with their to/from dates as board members there. That being said, we developed a hierarchy of the codes since there is a "primary" constituency code and we have constituents who fall into multiple categories (for example, we have someone who is an alum, is on our board of trustees and is also on our faculty, so that is 3 codes. Also we have business rules about multiple constituency codes and which ones you can have on an individual record based upon our needs. I feel multiple constituency codes cause nightmares for queries. We segment often on Constituency codes, so if you also find this to be the case, always take your Query into Export to clean up the results. Finally, it's important to establish who is allowed to add/change/delete a constituency code.

Best Practice: Constituency Codes

Comments

Categories