Constituency Codes - HELP

Marci Scott

My organization is looking at simplifying our constituent codes into: employee, alumni, trustee, Friend, Government, Foundation, Organization, Student. Media Gallery We will be tracking time relationships in attributes, for example former employee, former trustee, etc. Does anyone see any problems with this method? I want to catch things before they occur.

Sofia Bonnelly

Marci Scott:
My organization is looking at simplifying our constituent codes into: employee, alumni, trustee, Friend, Government, Foundation, Organization, Student. Media Gallery We will be tracking time relationships in attributes, for example former employee, former trustee, etc. Does anyone see any problems with this method? I want to catch things before they occur.

 Marcy, If you do not have the membership module, I also will recommend an action when they joined and when they are not longer part of the board, etc. You can create an action type or few action types depending of the board.

 

JoAnn Strommen

Marci Scott:
My organization is looking at simplifying our constituent codes into: employee, alumni, trustee, Friend, Government, Foundation, Organization, Student. Media Gallery We will be tracking time relationships in attributes, for example former employee, former trustee, etc. Does anyone see any problems with this method? I want to catch things before they occur.

Marci,

Is there a specific reason why you are opting to record 'time relationships' in attributes instead of using the "date from/date to" functions?  Do you have a plan for individual who was a trustee in past and becomes a trustee again that will allow for an easy querying/filtering on your attributes?  Will you be leaving all the "date from/date to" fields blank?  You'll just want to be consistent.

One suggestion I would make for tracking in attributes, especially when you may need to sort/filter on data, is to use tables whenever possible for your description field.

Do what works for you.

Melissa Graves 2

Marci Scott:
My organization is looking at simplifying our constituent codes into: employee, alumni, trustee, Friend, Government, Foundation, Organization, Student. Media Gallery We will be tracking time relationships in attributes, for example former employee, former trustee, etc. Does anyone see any problems with this method? I want to catch things before they occur.

I see having the same data in two places as confusing to users. Also doing any historical analysis will be near impossible.

Someday someone will ask you how much you raised from Employees in 2005 - without having someone have the code of employee 2001-2006 and former employee 2007-present - you can't get that data using a canned report - the same report you would use if someone asked what employees gave this year or for the past 10 years. You would have to run all kinds of queries and external analysis to get what should be a simple question if you use constituent codes as designed (where you include specific dates where that code applies).