Answers.Body: <p>I would start by reading the "<a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Tags+vs.+Groups+vs.+Custom+Fields" rel="nofollow">Groups vs. Tags. vs. Custom Fields</a>" wiki page, but most likely you can use any of the approaches you suggested successfully.  I personally don't use tags much when I only need to tag contacts; they can't be mailed to like groups, and they're not as neatly grouped as custom fields are.  So I'd consider groups, custom fields, or membership types.</p>
  
  <p>My main question would be how you intend to keep your data fresh.  Are you syncing in any way with your external system?  If so, importing custom fields or membership types is easier than importing groups.  Memberships are compelling because you can have different statuses, which would mesh well with your "reduced status" grace period.  The format in which you can export your other system's data (or better yet, connect automatically via an API) would be the deciding factor for me in your situation.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-29T14:02:32.090Z
Answers.Text: Thanks for the link - it cleared things up. Going to go with groups as far as I can. We're not syncing the data with any external systems, and since our billings system is horrible at exporting data I'll probably end up imputing everything manually…
Answers.UserDisplayName: Mateusz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-29T14:07:45.130Z
Answers.Text: The "suspended membership" status will probably end up as a regular group of it's own and us manually changing what the member belongs to. Especially since some people end up changing their suspension mid-year and activated. Might as well have the same setup for "ex members" who we'd still like to retain info on for membership stats.
Answers.UserDisplayName: Mateusz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-12-22T15:45:05.500Z
Answers.LastActivityDate: 2015-12-22T15:45:05.500Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>I'm setting up CiviCRM for our artist workshop, but after reading the good book I still haven't wrapped my head around how best to setup for the data I'd like to cover, so thought I'd check with my betters. Please advise.</p>
  
  <ul>
  <li><p>We are 1 organisation with 500 members, and each member can have
  access to 0-15 of our workshops (wood, textile, etc). Each workshop
  has 1 or 2 members who are admins for that shop. We have a board of
  trustees who all are members.</p></li>
  <li><p>We allow organisations to become members as well, and their employees
  are allowed in our shop, but they are not member themselves.</p></li>
  <li><p>We allow current members to become "inactive" for 1 year - retaining 
  their membership but with reduced access to the shop.</p></li>
  <li><p>We have a bunch of groups for tasks (events, exhibition, marketing…) 
  whose members are also members of the main organisation.</p></li>
  </ul>
  
  <p><em>I'd like to be able to selectively email all members of particular workshops, "task" groups and the board, as well as keep track of which member has been approved for which workshop when and by whom.</em></p>
  
  <p><strong>Q:</strong> 
  I was leaning towards creating groups for all above, but an alternative solution might be to use either custom fields or tags, and then use smart groups to generate email lists. Is there an advantage to either solution?</p>
  
  <p><strong>Q:</strong> I just found the "membership type" field - since we're doing our billing in an external system, is there any point in setting up the membership groups using "membership type" instead of "groups"?</p>
  
  <p><strong>Q:</strong> Some of our members are also members in other organisation we're dealing with, and I'd like to be able to sort those out as well. Would tagging those members with "acme inc" be the most straightforward way of doing that, or would it be better to setup a custom field allowing for more granularity? (i.e. "acme inc, press contact, interested in graphic design")</p>
  
  <p>Happy Holidays!</p>
  
  <p>Mateusz</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-22T19:05:00.760Z
Comments.Text: what CMS are you using? Do people 'log in' to the website? If so should Membership status (current, or grace, or expired) determine what they can see or do?
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-12-29T13:27:52.660Z
Comments.Text: We're using WP but members don't log in at the site at all. I'm going ot use CiviCRM just as a membership directory + email for starters, and further down allow our board and shop admins access so they can see members and do group emails based on workshop access / etc.
Comments.UserDisplayName: Mateusz
Tags: <groups><tags>
Title: Group, Type, or Membership type - please advise
ThreadText: # Group, Type, or Membership type - please advise
  
  (Asked by: username_0 on 2015-12-22)
  
  I'm setting up CiviCRM for our artist workshop, but after reading the good book I still haven't wrapped my head around how best to setup for the data I'd like to cover, so thought I'd check with my betters. Please advise.
  
  * We are 1 organisation with 500 members, and each member can have
    access to 0-15 of our workshops (wood, textile, etc). Each workshop
    has 1 or 2 members who are admins for that shop. We have a board of
    trustees who all are members.
  * We allow organisations to become members as well, and their employees
    are allowed in our shop, but they are not member themselves.
  * We allow current members to become "inactive" for 1 year - retaining
    their membership but with reduced access to the shop.
  * We have a bunch of groups for tasks (events, exhibition, marketing…)
    whose members are also members of the main organisation.
  
  *I'd like to be able to selectively email all members of particular workshops, "task" groups and the board, as well as keep track of which member has been approved for which workshop when and by whom.*
  
  **Q:**
  I was leaning towards creating groups for all above, but an alternative solution might be to use either custom fields or tags, and then use smart groups to generate email lists. Is there an advantage to either solution?
  
  **Q:** I just found the "membership type" field - since we're doing our billing in an external system, is there any point in setting up the membership groups using "membership type" instead of "groups"?
  
  **Q:** Some of our members are also members in other organisation we're dealing with, and I'd like to be able to sort those out as well. Would tagging those members with "acme inc" be the most straightforward way of doing that, or would it be better to setup a custom field allowing for more granularity? (i.e. "acme inc, press contact, interested in graphic design")
  
  Happy Holidays!
  
  username_0
  
  **Tags:** groups, tags
  
  > **Comments:**
  > **username_1**: what CMS are you using? Do people 'log in' to the website? If so should Membership status (current, or grace, or expired) determine what they can see or do?  
  > **username_0**: We're using WP but members don't log in at the site at all. I'm going ot use CiviCRM just as a membership directory + email for starters, and further down allow our board and shop admins access so they can see members and do group emails based on workshop access / etc.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2015-12-22. Score: 3
  
  I would start by reading the "[Groups vs. Tags. vs. Custom Fields](http://wiki.civicrm.org/confluence/display/CRMDOC/Tags+vs.+Groups+vs.+Custom+Fields)" wiki page, but most likely you can use any of the approaches you suggested successfully. I personally don't use tags much when I only need to tag contacts; they can't be mailed to like groups, and they're not as neatly grouped as custom fields are. So I'd consider groups, custom fields, or membership types.
  
  My main question would be how you intend to keep your data fresh. Are you syncing in any way with your external system? If so, importing custom fields or membership types is easier than importing groups. Memberships are compelling because you can have different statuses, which would mesh well with your "reduced status" grace period. The format in which you can export your other system's data (or better yet, connect automatically via an API) would be the deciding factor for me in your situation.
  
  > **Comments:**
  > **username_0**: Thanks for the link - it cleared things up. Going to go with groups as far as I can. We're not syncing the data with any external systems, and since our billings system is horrible at exporting data I'll probably end up imputing everything manually…  
  > **username_0**: The "suspended membership" status will probably end up as a regular group of it's own and us manually changing what the member belongs to. Especially since some people end up changing their suspension mid-year and activated. Might as well have the same setup for "ex members" who we'd still like to retain info on for membership stats.  
  
  ---
  
  