I am in the process of cleaning up my data and have noticed in RE we have many codes for constituents. I am trying to get insight as to how other organizations handle their coding. My plan is to dwindle down the const codes to a small number and add attributes to replace some of the codes I want to take out. We are a school so we do not have members. Any help would be much appreciated

Our codes are: Church Civic Organization Daily Pickup (for our food bank's use) Estate Executive (used to limit other department's rights to executive records) Foundation Government Individual John C. Internal Group (Departments within our network) Lincoln Gives (Our employee giving program) Organization School United Way I'm interested to see what codes other organizations use as well!

Individual FOundation Family Foundation Business Media Vendor Organization College/Uni Government Matching Gift Co Veronica D'Amico Scenic Hudson, Inc. [Email Removed]

I've had several issues with const., codes. We started using the "Date from" and "Date to" fields to help us weed down the multi const., codes. For example: Board Members would use to have a "Board Member" Const., code and a "Former Board" const., code and then we stared using the "Date From" & "Date to" fields. Well, that game plan went all wrong! Using those two fields causes issues in queries even when you are very exact in query as to whether or not your records have a start and end date. So to make a long story short, you may still need more than one code for some const., codes. I hate using attribute for some of this since that's the "Catch all" area and can get bogged down as well. When I worked at a school we had the following: Current and Former Student, Current & Former Parent, Current and former Grandparent, Current and Former Board, Business, Foundation, Matching Gift company, Alumni, Government, United Way, CFC, Workplace Giving. Feel free to contact me directly Susan E. Zolbe Database & Stewardship Manager Capital Hospice Email: [Email Removed]

You should always be careful when using dates on constituent record constituency codes (as opposed to gift record) if you are planning to run any kind of gift related reports that you want to tie out financially. I have found that if a constituent doesn't have an active code during a date range you are querying on - then their gift can get left out of the mix. For this reason I do not use dates on my constituency codes - I just use the hierarchy structure because of the way we like to do reporting based on constituent as opposed to based on gift. Laurel Quaintance Friends of Bassett Manager,Fund Development Services Cooperstown, NY 13326 [Email Removed]

Thanks everyone for your feedback. Here is a list of our current Codes: AL - Alumni AP - Alumni Parent GPA - Alumni Grandparent BD - Board CV - Campaign Volunteer CO - Corporation D - Deceased DNS - Do Not Solicit FA - Faculty FB - Former Board FF - Former Faculty FO - Foundation FR - Friend GR - Grandparent HM - Honor/Memorial CAIS - Independent Schools ML - Mailings MSC - Miscellaneous NP - New Parent NCC - No Campaign Contract NC - Non-Custodial Parent OC - Organization Contact OCS - Organization Contact Spouse P - Parent PG - Parent Guild PP - Past Parent PND - Pending PNDGP - Pending Grandparent SOL - Solicitor ST - ST TAG - tag OR - Organization ng - New Grandparent 07-08 - New Parent 07-08 A - sTAFF alumni - Alumni Grandparent former - former gradnparent ACK - thanks to be sent to business as you can see we have quite a few that need to be taken out. Any suggestions?

We have Primary and Secondary codes. Each record must have a primary code: Alumni/ae, Friend, Alumni/Board. Friend Board, Faculty/Staff, Student, Foundation, Corporation, Organization, Government, school, media. Secondary may be used for: Advisory/Honorary Board, Former Fac/Staff, Former Board, Current Parent, Legislative Official. -- We use the secondary codes as a quick reference on Biotab1 to further define a constituents involvement from the two primary or Alumni and Friend (all non alumni individuals) We pull all reports off the primary code. Nina Williams The Cleveland Institute of Art www.cia.edu Making Art Work [i]--- Edited at 2/1/2008 9:18:52 AM by Nina Williams[/i]

Many of yours can be migrated to other areas of the database to be used appropriately.

Example:
Do Not Solicit and Mailings could be moved to Solicit Codes

All of the ones that are 'contacts' could be set up as actual contacts

All of the ones that are Solicitors could be set up as solicitors

This would allow you to use constituency Code for what they really are: (Example - couldn't alumni, Board and campaign Volunteers be Solicitors for your organization? Couldn't they also be contacts for an organization that has a relationship to your school?

That's where I would start... Laurel Quaintance
Friends of Bassett
Manager,Fund Development Services
Cooperstown, NY 13326
[Email Removed]

I am concerned about the number of responses in this thread that warn people not to use dates on constituency codes. I never had such problems and found them to be very useful. If someone did not have an active constituency code during a timeframe and made a gift during that timeframe then there is something seriously wrong with that record and it is likey violating policies you should have regarding constituency codes. I found that on reports it was fantastic to use timeframes and report on constituency codes and the report automatically pulled the correct constituency code for that timeframe. It may take practice and adherance to some new policies but I would suggest that in many cases dates on constituency codes will be helpful. *** I can spell, I just can't type. Where is spell check? Melissa S. Graves Director of Development Services The Village for Families and Children mgraves @ villageforchildren.org

I have also had success using dates, especially when a record changes from an idividual to an estate (the person passes away). It seperates the previous gifts when the person was living from the estate gifts in our reports.

Andrea here are my thoughts on your list D - Deceased (not a constituency code - this is a duplicate of the deceased flag) DNS - Do Not Solicit (solicit code or attribute is a better place for this) FR - Friend (why not just individual?) HM - Honor/Memorial (not necessary - you can get this either from the tribute module or the gift tab) ML - Mailings (what is this used for?) MSC - Miscellaneous (huh?) NP - New Parent (why new and not just parent?) NCC - No Campaign Contract (huh?) OC - Organization Contact (these should be in relationships) OCS - Organization Contact Spouse PG - Parent Guild (how is this used? If on individual members then this could be a relationship or an attribute) PND - Pending (how is this used?) PNDGP - Pending Grandparent (huh?) SOL - Solicitor (not necessary - you have the is a solicitor checkbox) ST - ST (?) TAG - tag (?) ng - New Grandparent (why new not just grantparent?) alumni - Alumni Grandparent (is this just past grandparent like past parent?) former - former gradnparent (ditto?) ACK - thanks to be sent to business (acknowledgements by law need to be sent to the donor who made the gift. If they want it sent to their business address then make thet their primary address or add an address attribute to their business address to make sure it goes there. Do not confuse that with acknowledging the business.) In general it looks as if cons codes were too frequenly used as attributes which is the appropriate place for miscellaneous codes. Also it is apparent that many of them are duplicates of other existing codes (like deceased and solicitor). It may be difficult to wean users off of what they see as the convenience of having all of these codes where they are but it makes for a very messy database and errors come from messy databases. *** I can spell, I just can't type. Where is spell check? Melissa S. Graves Director of Development Services The Village for Families and Children mgraves @ villageforchildren.org

If you have a database that was inherited and the constituency codes used at different points in the system made no sense you may be in a situation where you do NOT want to use the constituency on the GIFT for reporting puropses. We use the constituency code off of the constituent record for all of our reporting purposes especially when we are doing comparisons, etc. The problem that can occur with using dates on the constituency code would be if you are using query in any of your reports. If your selection criteria uses the date range and you do not have dates on a constituency code or a donor does not have a code on their account they will be left out of the query. My boss likes to be able to match revenue reports of total giving to these little subsets spanning multiple years. Finding the donors that are 'missing' can then become time consuming and I find it makes me not always trust my numbers. Many people that are not 'super-users' may not understand the ramifications of using date ranges on donors and how they could 'accidentally' miss someone in a selection. Example: If you run the Gift Detail & Summary Report and you use constituency code in filters and run lists for each constituency code during a certain time frame & add them all up you may expect the totals to be the same as if you ran the report with no filtering - which would not be the case if a donor didn't have a constituency code that fell into that date range. I'm not saying my way is the best for everyone - it works for me. In Higher Education I could see where Student, Alumni, Board Member on the same account with corresponding date ranges for each would be appropriate. The Primary Constituency code works well for me. Laurel Quaintance Friends of Bassett Manager,Fund Development Services Cooperstown, NY 13326 [Email Removed]

Hi! We have talked about database clean up as well. When we first got Raiser's Edge (a long time ago - previous versions) - I think that codes were added because they seemed like the right thing to do. The person who entered gifts before me had a much better understanding and when we converted to RE7, she attempted to have the entire office give their opinions on constituent codes, etc. Then she left and I got this job. Not knowing a lot about RE and this kind of work in general, it took some time to fully understand what constituent codes are and how they should be used. Fast forward quite some time later - and we (the Foundtion Office) is looking into ways to clean up our database. We decided to work with constituent codes. We decided to try to have only a few main codes: Administration Boards Employees Volunteers Government Bequests Now I'm pulling queries of all of the Constituent Codes that we have and trying to fit what we have into the 'new few' and adding attributes to answer the 'what we had' question(s). However.....for instance, an employee who has left - do I add a constituent code of 'Ex-Employee' or do I take that constituent code out and add Ex-Employee to Attributes (or somewhere else)? Any ideas or suggestions would be greatly appreciated. Thanks. Heidi Cimilluca Gifts Coordinator Hunterdon Medical Center Foundation Flemington, NJ

I would go with the constituency code for ex-employee. This would be the easiest way to run a query if needed. You can also globally change the code or delete it. But I agree with the previous reply to not use the date range would be best.

I hesitate to make employee or ex-employee a constituent code. Regardless of employment status, an employee is a individual. We have ours coded as an attribute. What if an employee gave before and gives after their employement ends? Veronica D'Amico Scenic Hudson, Inc. [Email Removed]