constituent codes vs. attributes

Options
We seem to have more constituent codes than necessary, some should be attributes.  I'm new to this organization and I would love to see samples from other hospital foundations as to your list of constituent codes and your list of attributes.  Anyone willing to share?  Thank you!
Tagged:

Comments

  • We are a healthcare foundation(s), each associated with a hospital and each using the same RE and NXT. Therefore we have constituent codes to delineate one foundation from another. Each constituent will have that code. We'll then add others as needed but try to keep the number of different codes to a minimum. But codes we also use include:

    Board member

    College of Nursing (we have a nursing school)

    Legacy (this is a specific kind of donor)

    Volunteer


    We have others but I think they are peculiar to our foundations and are used for reporting purposes.


    We have some old ones that are not used anymore that, IMO, did not make sense as a constituent code:

    Friend

    Donor

    Organization

    Church

    School

    Prospect


    They don't belong as a constituent code.


    Use attributes to explain why someone or an org. is in your database.

    I hope this helps.

     
  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic

    Mark Guncheon:

    We are a healthcare foundation(s), each associated with a hospital and each using the same RE and NXT. Therefore we have constituent codes to delineate one foundation from another. Each constituent will have that code. We'll then add others as needed but try to keep the number of different codes to a minimum. But codes we also use include:

    Board member

    College of Nursing (we have a nursing school)

    Legacy (this is a specific kind of donor)

    Volunteer


    We have others but I think they are peculiar to our foundations and are used for reporting purposes.


    We have some old ones that are not used anymore that, IMO, did not make sense as a constituent code:

    Friend

    Donor

    Organization

    Church

    School

    Prospect


    They don't belong as a constituent code.


    Use attributes to explain why someone or an org. is in your database.

    I hope this helps.

     

    That is interesting Mark Guncheon‍.  Especially in regards to prospect.  What is your constituency hierarchy?  I'm working on culling my constituent codes, and I struggle with the codes of Donor and Prospect.  I need that prospect code for those individuals that my fundraisers are working on.


    In regards to your original question Allison Ebert‍, I think the biggest thing is determining what you'll need to report on.  I had/have the same issue, but I have found that some of the codes that I thought were superfluous were codes that I have found to be the biggest reporting tools that I have.  I'd recommend a constituency pivot table to find the codes that have the fewest members, and determine if they are needed and delete where necessary.

  • I'm interested to hear more on this as well - also constituent code or solicitor relationship.

    We have a CEO and a CDO constituent code that we use to identify lists for each of them when we do special mailings or appeals that they want to personalize.  I was told this is an incorrect way to use constituent codes and to move them to solicitor relationships as relationship managers, but that has caused them to be added as the solicitor on all gifts each of those constituents give which isn't really correct.


    What are other Orgs using to identify lists?  We have RE7, not NXT.


    Thanks1

    Tiffany
  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic

    Tiffany Harder:

    I'm interested to hear more on this as well - also constituent code or solicitor relationship.

    We have a CEO and a CDO constituent code that we use to identify lists for each of them when we do special mailings or appeals that they want to personalize.  I was told this is an incorrect way to use constituent codes and to move them to solicitor relationships as relationship managers, but that has caused them to be added as the solicitor on all gifts each of those constituents give which isn't really correct.


    What are other Orgs using to identify lists?  We have RE7, not NXT.


    Thanks1

    Tiffany

    They don't need to be solicitor relationships, as much as contact relationships.  You can set the contact type as CEO or CDO, and query off that.

  • JoAnn Strommen
    JoAnn Strommen ✭✭✭✭✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic
    I agree with Dariel Dixon‍ .  A relationship is a better option IMO.  Using relationships also means that each COO/CEO does not have to have their own record in RE if you don't want to.  My second choice would be an attribute.  The CEO/COO doesn't fit our description of constituent code.
  • Thank you Dariel Dixon and JoAnn Strommen!  Can I pick your brains a little further - we are currently using the contact type CEO on Org records to identify which relationship with the organization that our CEO holds as sometimes her relationship isn't with the primary day to day person on the record.  I could create a variation of the type for the lists, however how would you add the relationship on individual records?  I want to ensure I can pull one list with ease.


    Thanks again for your help!

    Tiffany
  • On the individual record, go to the relationship tab and add an org. relationship for the connecting organization, clicking on the CEO contact type. 
  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic
    Just like Mark Guncheon‍ stated, just add the contact type to the relationship.  The relationship type is just reversed - Organizational relationship for individuals, and individual relationships for orgs.  


    Just pick what you are going to call the contact type, and be consistent.  As long as the type is the same, you should be able to pull them in at the same time.
  • Hello!


    I have just joined an organization which has a relatively small RE database.  The organization has been going for a while and the lines between Attributes and Constituent Codes are somewhat blurry and repetitive in some cases.


    I am wondering if there is any general guideline in terms of what should be a Constituent Code and what should be an Attribute?  Also - if there is one that is more useful than the other?  When it comes to reporting etc?


    For example - if we have a member of our Board of Directors.  It is currently noted under a Constituent Code - but if I was to make it an Attribute, I could then set a drop down table with - Current, Former - etc?  


    Any help that could be offered would be great!


    With Gratitude,

    Beth
  • JoAnn Strommen
    JoAnn Strommen ✭✭✭✭✭
    Ancient Membership Facilitator 4 Name Dropper Photogenic
    I'm working on a clean up of the same issue.  IMO, constituent codes should answer question of why is this record in our database - what's the relationship.  I find constit code easier to filter on for queries and reports.  


    Board is often a constit code as that may be the primary reason record is in RE and you may need to do reports by board giving etc. While some do not use the date from/to fields, I've found that it works fine for us to differentiate current and former. One way to record more info is to create a record "Our Board members" with a relationship to individual records so that you could note dates and positions.


    I've also used the constituent code with additional info in attributes like "staff" and then attribute for "department." 


    Nothing conclusive, just some thoughts.
  • Beth, the constituent codes have a from and to date that can help with making it more clear. You could also add a "Former Board Member" constituent code. Relationship tab is the best place for board information though IMO.


     
  • Thank you for the speedy responses!


    I think I have a clearer picture - of what goes where, but its also interesting to note there are really no hard rules on Constituent vs. Attribute!


    With Gratitude,

    Beth
  • Karen Diener 2
    Karen Diener 2 ✭✭✭✭✭
    Ancient Membership Facilitator 3 Name Dropper Photogenic
    JoAnn Strommen‍ is correct about how to think about the constituent code - it should answer the question "why is this person or organization in my database".  I'm also an advocate of NOT using constituent codes to explain something that already exists in your database, like Donor.  You can tell someone is a donor by their giving.  And every time I've worked in a database where Donor is a code, I have found LOTS of records marked as Donor with no giving.  I've also found "Prospects" with giving.  And constituents marked with both Donor and Prospect.


    Attributes don't have rules around them, simply because they are meant to store data that has nowhere else in the database to "live".  But they can very quickly become the junk drawer, so be thoughtful about what you put there, how you construct the attribute, and document the heck out of each attribute.  When it should be added, how and why it should be done in a specific way, how to maintain it, if it needs maintenance of any sort, etc.  For that matter, document the constituent codes with the same amount of enthusiasm as the attributes!


    Karen
  • Dariel Dixon 2
    Dariel Dixon 2 ✭✭✭✭✭
    Seventh Anniversary Facilitator 4 Name Dropper Photogenic
    While I also hate the "Donor" constituent code, I do find that it serves a purpose.  Granted, it is a code of some redundancy, but it does fill a need when other constituency codes don't fit.


    It's not a bad thing that attributes are as generic as they are.  Also, attributes have different types, allowing them to be more flexible than just a code.
  • Don't forget that when managing your constituent codes, the top one will automatically pull into the Gift Constituency, which you can use for gift reporting. If a constituent has more than one code, the data entry person can choose which constituency matches the gift - if, for example, you're set up like Mark Guncheon's org and use constituent codes to identify which hospital a donor is affiliated with, should that donor choose to donate to multiple hospitals.


    When evaluating your constituent codes, the gift constituency may influence which ones you keep, or change/merge, or how you make adjustments to the code table. (I believe the gift constituency also has a heavier weight in some of the NXT report builder options than record constituency... and of course Bill Connors has some good suggestions about why you might not want to use "Former" as a code, if you're using the RE Reports.)


    I'm being reminded of a lot of little things like this lately, as I have moved to a smaller org where I'm doing more of the day-to-day data entry as well as the big data management/reporting pieces. :)

Categories