Answers.Body: <p>These are not the easiest of questions and we may take different approaches. EG we tend to use Custom Fields a lot more than Tags, others do the reverse.</p>
  
  <p>Sometimes it only becomes clear after you have set things up and used them one way, and therefore it can make sense when trying civi out to try multiple approaches.</p>
  
  <p>As you have spotted, Groups are the solution if people are signing up for eg Mailing lists, but even then it could be that the Group is a Smart Group built off a custom field.</p>
  
  <p>To take a stab at your list examples like Endorsers sound like a Tag.</p>
  
  <p>But a Relationship (civi term) is good when you want to keep track of start/end dates, eg if someone was a Partner in 2012-2014 since the history is recorded.</p>
  
  <p>Similarly when you say 'Council', if you mean eg John was on the Council in 2012, then creating a 'contact' for 'council' and giving John a relationship of eg 'council member' means you can both see current council members, and former ones.</p>
  
  <p>Also which CMS you use can make a difference, for example in Drupal you can use Views to publish members of a council, by constructing a View based on Civi Contacts that uses the drupal and civi concept of a Relationship to show all the contacts who have a current Relationship to the contact that is your council.</p>
  
  <p>Hope that helps a bit</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-11T21:29:25.580Z
Answers.Text: This is very helpful.  Thank you.  I did not realize I can create Smart Groups from custom fields, which is probably better than a simple Group.  And your suggestion for using Members when there is a start and end date is really important.  Thank youl
Answers.UserDisplayName: Nina Gonzalez
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-12T01:27:13.883Z
Answers.Text: Glad it helped, though i thought i was suggesting Relationships rather than Memberships
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-17T19:05:34.367Z
Answers.Text: ok, thanks for the clarifications.  I'll look into Relationships.  I thought relationships were used for employee-employer relationships. I did not think it would be used for endorsers, partners, affiliates, etc.
Answers.UserDisplayName: Nina Gonzalez
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-11-10T19:59:24.753Z
Answers.LastActivityDate: 2015-11-10T19:59:24.753Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>Still new to CiviCRM and grateful for opinions and advice. We have several types of relationship with organizations. We do not charge anything for any type of relationship.  Relationships are managed in the backend only, hence controlled by staff members who login to backend.  Relation types include endorsers, partners, affliates, council, past council, volunteers, etc. </p>
  
  <p>Some groups will be listed and published on the website, so I know to manage them as "groups" since that is the only way to have a public list on a website.</p>
  
  <p>What is the best way to handle the rest? Membership doesn't seem to fit since it requires some financial relationship, although 'zero' is possible.  Perhaps this is just a multiselect custom field?</p>
  
Tags: <civimember><custom-fields><relationships>
Title: Membership Types vs Groups vs Organizational Types vs Relationships
ThreadText: # Membership Types vs Groups vs Organizational Types vs Relationships
  
  (Asked by: username_0 on 2015-11-10)
  
  Still new to CiviCRM and grateful for opinions and advice. We have several types of relationship with organizations. We do not charge anything for any type of relationship. Relationships are managed in the backend only, hence controlled by staff members who login to backend. Relation types include endorsers, partners, affliates, council, past council, volunteers, etc.
  
  Some groups will be listed and published on the website, so I know to manage them as "groups" since that is the only way to have a public list on a website.
  
  What is the best way to handle the rest? Membership doesn't seem to fit since it requires some financial relationship, although 'zero' is possible. Perhaps this is just a multiselect custom field?
  
  **Tags:** civimember, custom-fields, relationships
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-11-10. Score: 1
  
  These are not the easiest of questions and we may take different approaches. EG we tend to use Custom Fields a lot more than Tags, others do the reverse.
  
  Sometimes it only becomes clear after you have set things up and used them one way, and therefore it can make sense when trying civi out to try multiple approaches.
  
  As you have spotted, Groups are the solution if people are signing up for eg Mailing lists, but even then it could be that the Group is a Smart Group built off a custom field.
  
  To take a stab at your list examples like Endorsers sound like a Tag.
  
  But a Relationship (civi term) is good when you want to keep track of start/end dates, eg if someone was a Partner in 2012-2014 since the history is recorded.
  
  Similarly when you say 'Council', if you mean eg John was on the Council in 2012, then creating a 'contact' for 'council' and giving John a relationship of eg 'council member' means you can both see current council members, and former ones.
  
  Also which CMS you use can make a difference, for example in Drupal you can use Views to publish members of a council, by constructing a View based on Civi Contacts that uses the drupal and civi concept of a Relationship to show all the contacts who have a current Relationship to the contact that is your council.
  
  Hope that helps a bit
  
  > **Comments:**
  > **username_0**: This is very helpful.  Thank you.  I did not realize I can create Smart Groups from custom fields, which is probably better than a simple Group.  And your suggestion for using Members when there is a start and end date is really important.  Thank youl  
  > **username_1**: Glad it helped, though i thought i was suggesting Relationships rather than Memberships  
  > **username_0**: ok, thanks for the clarifications.  I'll look into Relationships.  I thought relationships were used for employee-employer relationships. I did not think it would be used for endorsers, partners, affiliates, etc.  
  
  ---
  
  