Attributes

Options
Would the Attribute tab be a good place to track which constituents belong to various committees within the organization?

Comments

  • Donna Wolfgeher:

    Would the Attribute tab be a good place to track which constituents belong to various committees within the organization?

    Donna -

    We use attributes to track things like that


    A Constituent Code would be another option, but I prefer an attribute for something like this

    Joanne

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

    Depending on your need for the data, another option is a record for the committe and relationships to the individuals serving on the committee. It they are large committees and you want to show from/to dates the relationships work well. Gives a few more query options IMO. I wouldn't probably do for tons of small committees.


    I've done this for our board after seeing it suggested on the forums.
  • Short answer: Yes.


    Long answer: Absolutely.

     
  • Donna Wolfgeher:

    Would the Attribute tab be a good place to track which constituents belong to various committees within the organization?

    We use relationships -- create the committees as orgs and link the members to it. You can store more information this way, including positions, date from/to, information about the committee itself, etc.

  • If you have the Volunteer Module, that's another option for you.

  • Donna Wolfgeher:

    Would the Attribute tab be a good place to track which constituents belong to various committees within the organization?

    We currently use attributes to track this, all it advises is what committee they are a member of and the date they became a member (Date of attribute). However, we are now slowly looking to move this across into relationships where we will create the committee as an organisation and link individuals to it. We have found we need more information , such as their level of membership, full dates, important attributes relating to that specific relationship etc...It is much easier to store and query on in relationships. Unfortunately we have years and years worth of data to move across... So i would say it depends on what you think your needs will be with the data, if you literally just need numbers on how many people belong to a committee then attributes work fine, but if you need to dig deeper then it may be worth considering relationships now to save you the hassle of moving data across in the future.

  • Thanks—others are using relationships as well.
    We might consider that.

     

    Donna
    Wolfgeher

    Executive
    Assistant

    Catholic
    Education Foundation (CEF)

    www.cefks.org

    12615 Parallel
    Pkwy

    Kansas City, KS 66109

    913-647-0344

    dwolfgeher@archkck.org

     

          

     

     

     

     

  • I would also suggest looking at Constituent Codes. At my last organization, we recorded members of the Alumni Council, the Board of Trustees, and the Foundation Board this way. We used the to and from dates, but when they left the board or council, we would change the Constituent Code to "Former Alumni Councilor" or whatever was appropriate. We did this becuase we pulled lots of other things based soley on their membership in one of these boards, especially mailing lists. It was easy to include or exclude based on Constituent Code, where it wouldn't be as easy to do so from Relationships. 


    That said, if you have a Constituent Code that is the primary connection with the person, and they are rotating members of several committees, I would probably go with a combination of Attributes with Notes. I just found Relationships so cumbersome it was really annoying when it came to queries. If I were using Relationships, I don't think I'd create each committee as a separate organization - that seems like too many non-constituent records to keep organized but I guess it depends on how important these committees are to your operations and reporting. In Attributes, I'd use the date as an "expiration" date to grab all who were still on the committee (greater than today), or leave the date blank for current members and put the end date in (Attribute date = blank). The comments could be used for whichever date you didn't use in the date field, and/or their office (if any) in the committee (President). I'd then make a Notes category of "Committee Activity" so you could easily pull all notes on just that, and make the description of the first and last one just "Joined Committee (Treasurer) 01/01/18" and "Left committee 12/31/18" or similar. That's easy to read quickly in the Notes page.


    Gracie Schild

    Bluebird Business Services

    Santa Fe NM
  • Thanks, Gracie. I agree with you about the relationships in queries. very cumbersome.  We have 12 committees and the biggest has 16 members. We don't care about the to and from part.I find them very easy to query putting them in attibutes. When it comes time to add or take off we'll just delete that attribute as we don't need that history. Thanks for taking the time to answer!

Categories