Best practices for coding board members in RE ?

We use constituency codes, but don't use the "to" date as my staff found date ranges too difficult to remember when pulling information in query. We also give them a volunteer constituency code which stays active until they die. To move active board members to inactive members we change the code to Former board. We also create a note called Committee/Boards to track the board members service and committees on which they served. We do not have the volunteer module. This may seem a bit cumbersome, but it works for us and all staff understand the process.

 

We had been using Attributes to track board and council membership for the university as a whole, but we had the same problems. We have something like 30 boards and councils, minmum, and some constituents may belong to multiple, or they may have gaps when their first term ends and they wait a few years before their second term.

This year, we have begun transitioning from Attributes to Memberships, since we already have the module for some of our auxiliary institutions and a couple boards were using it with success. This works handily because a few of the councils have dues requirements, and with Memberships we can track whether the dues were paid for the council term (using Linked Gifts). We can also use Membership Programs to group the councils by division or college and Subcategories or Membership Attributes to track specific council committees or positions. (Which one is used depends on the council's rules - which, admittedly, is a bit of a headache to keep track, but it was nearly impossible to do with Attributes.)


I have found that it is very, very helpful to create a tree/relational map of the various university colleges and divisions, their boards and councils, and any committees or other subdivisions. This is stored with our Memberships policies and procedures and will be updated prior to each academic year. The Membership Program -> Category -> Subcategory is the same breakdown, but it's nice to see them laid out in the reference file instead of having to visualize it from the Config tables and settings. It's also a good reference for our data entry staff, who of course do not have access to the Config settings.


To be honest, our solution is really only necessary if you have a huge number of board members and need to be able to see their history with the organization. It's a little complicated to set up, but once it's done, the term dates automatically remove the board members from the active roster, so I only have to worry about adding or renewing the board membership and linking their dues.

I'm reposting a response from Aaron Rothberg in a previous thread - which is how I also handle board members (in the thread they were discussing committee members but it's the same thing ...):

I'm a huge proponent for tracking committee members and board members using Ind-> Org relationships. You've already noted some of the downsides of using Constit Codes to track this data especially when a constituent may belong to more than one Committee and those memberships can change over time. If the person joins the committee, leaves the committee, and joins the committee again you now have two Constit Codes to track that changing relationship. Constit Codes also limit you to capturing one start date and one end date and not much else about the committee relationship. It's true that should you choose to use Relationships moving forward (which I recommend) you would also have two Rels on the Relationships Tab, but relationship records allow you to track much more information such as the constituents position on the committee, if s/he is a contact for the committee, if the constituent has phone numbers or email addresses specific to the committee. Our process includes that if someone leaves the committee, we change their relationship to Former Member which allows me to filter them out of Export by Relationship Type, but we leave the dates intact so we can see when that person was active on the committee.
 
Once I started tracking committee relationships using Ind -> Org Rels and discovered the advantages of going that route I never looked back.