How many Constituent Codes do you assign to a single Constituent?

Options
I've been the DBA for my higher ed. organization for two years now (not too long). In my short time, however, I have found that we might be one of the only organizations that use just one constituent code per record in our database.  After completing just about every webinar BB offers for RE and RE NXT, attending BBCON, and networking with like institutions - we seem to be the outlier. 


I've have realized the way we've set up our constituent codes, we either lose some historical information on our constituents, or we have to go around our elbows to get to our noses to export the information from RE. 

 For example: 


We code our Alumnus who work for the university as a professor and is a parent of a current student as an ALUMNUS PARENT FACULTY


Now, when the professor retires and/or the student graduates, the constituent in question switches back to just ALUMNUS - dropping both parent tag and faculty tag. 


We have to query by relationship type to get previous parents or retired fac/staff, which can be overly complicated.  For former Trustees/board members, we have a free text field in attributes that's almost impossible to query correctly on.  Without continuing to go on and on, I'm seeing more and more issues with clean, accurate data.



All this to ask:  What is your institutions best practice for constituent codes?  How many do you assign? What do your procedures look like?


We're about to move to NXT in March and hoping I can convince my institution that it might be beneficial to use more than one constituent code moving forward. I'll take any advice/help I can get!


Thanks!

Comments

  • I work at a K-12, and we do use more than one code per constituent where warranted. In your example, ours would be come Alumni, Parent of Alumni, Past Faculty. My org has elected not to use to/from dates on our constituent codes, but that information is contained in the relationship record so it has not caused us too much hassle. 


    I would also echo what JoAnn said - have a hierarchy for your codes. For us, a current Parent "outranks" an Alumni. Take a look at your fundraising initiatives and strategy, and be sure to document whatever your org ends up doing!
  • As many as warranted. I use constituent codes as descriptors for how the constituent is related to us. So if they're an adopter (we're an animal shelter), they get an "adopter" code, but they may also be a volunteer, recurring monthly donor, gala attendee, and walk-a-thon participant. Those are all codes. Every month I go through a bunch of global changes that will add or remove codes based on whatever query parameters are associated with each.


    Honestly there's so much overlap here that the codes are only rarely useful, so I may not be the best person to answer now that I think of it. 
  • We use the one constituent per record rule.  If a person is an Alum and Med. Staff, their conscode is Med. Staff and their attribute of Secondary Affiliation is Alum.  We also us an attribute of past affiliation; so if a Med. Staff leaves, his/her conscode would go to Alum and their Past Affiliation would become Med. Staff.  We have differing variances for each situation.  It allows our reporting and queries to be much cleaner.
  • Elaine Tucker
    Elaine Tucker Community All-Star
    Ancient Membership 500 Likes 100 Comments Photogenic
    We use to and from dates for ONLY 3 of our constituent codes: Board Member, Staff, Intern. This is especially helpful with the Board, because our board members are elected for a 3 year term, can run for a second term, and then after 6 years of service MUST take at least a year off.  Then when they come back on that board term is added to their constituent code.  Board Member out ranks all other constituent codes. 


    Our other constituent codes allow for as many as needed as other posters have mentioned, but the best practice is to have a hierarchy for those with multiple codes.


     
  • If one is a Board Member for a number of years and then is no longer on Board, do you add code of friend or donor so as not to remove them from data base?

     
  • Dariel Dixon:

    If I'm understanding this correctly LINDSEY COPELAND‍, you use one code per record, but also have multiple variations of that code for each combination of codes?  


    So instead of just having a parent code, you would have alum parent, Faculty parent, alum parent faculty, etc.  Then I guess you still have just the parent code for those individuals who only have that relationship.  That sounds like a difficult tedious process to navigate.  I don't know what is gained by this structure.  If you're using combination codes, your organization has already determined that individuals can have more than one constituency concurrently.  Then why not use multiple codes, and make life a little easier.  You are exchanging cleanliness in your records to a crowded constituency code table.


    I agree with JoAnn Strommen‍, in that your hierarchy of codes should be the determining factor here.  I definitely agree that you can get too crazy with constituent codes, but sometimes there's really no other way.  I usually have to take a step back and think about how the codes will be used.  Sometimes a constituent can have too many codes that they are included in everything, and/or excluded from nothing.  But you'll know where the tipping point is for your organization.

     

    It is definitely tedious.  At the end of every semester and the end of both calendar year/fiscal year, we have to run several queries to find those who have phased out of their current constituent code. For example:  Alumnus parent whose student graduated in December shifts back to just an Alumnus.  Although I believe our database to be pretty clean, the queries never catch everything and some manually follow-up always has to happen.  Your feedback is right on the money.  I inherited this system and all these comments are really useful in helping persuade my team it might be a good idea to try another way!

  • Maura Coppola:

    If one is a Board Member for a number of years and then is no longer on Board, do you add code of friend or donor so as not to remove them from data base?

     

    Maura Coppola‍   - our board members have whatever constituent code is their affiliation to the university (Alumnus, Parent, Faculty, Friend, etc.).  We use attributes to track board/council members.  Unfortunately, the system was set up where dates of service are not tracked.  It's manually added as a range in the COMMENTS field -- which is free text and nearly impossible to query.  

  • We recently modified our coding and only use one code per constituent in order to more easily see where our gifts are coming from.  We use education relationships to track info on parents, students, grandparents.  The class year determines current student or alumni status (so we never have to change student status to alumni), and the parent/student/grandparent information is added in school type.  We track board service under attributes with their start date listed.  Their term is put in the comment section.  Faculty and Staff are listed in an employee relationship to the institution "mothership", which is a constituent.
  • I may be an outlier here as well, but in my experience I really prefer that constituent codes describe the constituent, who they are, rather than their relationship for us. For example: individual, corporation, church,foundation, etc. and then use attributes to describe their relationship to us, for example: board member, committee chair etc.


     
  • At my former organization (I'm a consultant now), we tried to keep it to no more than two or three codes per constituent, and they reflected the most important relationships with the college. We did use dates for Board members, but we changed them from Board to Former Board Member when they left, just so that regular lists were easy to pull. We had 30 or so different Constituent Codes, but the most I allowed after a huge clean-up was three: something like Alumni and Faculty/Staff was pretty common. We had Former Faculty/Staff as well - same deal as with the board. For people who didn't have any special relationship, we just used Individual or Organization, and then changed them later if desired. I did delete those generic ones when we added something useful. I'm not a fan of insisting on just one - the alumna who joined the staff is a perfect example: we want to include her in all the alumni related mailings, but exclude her from general fundraising letters because she was staff. Anything more granular went into Attributes.


    Gracie Schild

    Bluebird Business Services

    Santa Fe NM
  • We also use as many codes as warranted, but rely on a priority hierarchy to determine which code gets precedence.  We use the codes to indicate what relationship the person or organization has to us, with the hierarchy based on what we would want to know first about that entity. For instance, someone in our organization could be coded as a Current Board Member, Donor, Volunteer, Adopter.  We don't use constituent codes to indicate event participation - for that, we'd pull based on event attendance. We also don't use constituent codes to indicate monthly donors - we use attributes for that.  Organizations rarely have more than one code, however - that tends to be defined as what type of organization they are - e.g. Corporation, Foundation, Community Group, School/Educational Institution.


    Hope that helps.


    best regards,

    Katie
  • Wanting to send a general thank you to everyone who commented.  Every. Single.  Comment. was very useful to me and helpful!


    THANK YOU THANK YOU!!
  • How do you set up a Hierarchy of Codes? Is it how the constituency code is listed or is there an area in RE that allows a hierarchy set up?

  • JoAnn Strommen
    JoAnn Strommen Community All-Star
    Ancient Membership 2,500 Likes 2500 Comments Photogenic

    Unless something has changed that I'm not aware of, it's totally based on the order they are listed on the record.

    While a hierarchy master with in REwould be nice it could be fairly complex for org who use multiples and multiples. We have a list of our hierarchy in our data entry procedures.

Categories