Answers.Body: <p>It sounds like departments, teams, and sub-teams could be set up as contact sub-types of the organization contact type, possibly with custom relationships between each that are intuitively named, as described here:</p>
  
  <p><a href="https://civicrm.org/blogs/mjpforsberg/using-contact-subtypes-clutter-free-life" rel="nofollow">https://civicrm.org/blogs/mjpforsberg/using-contact-subtypes-clutter-free-life</a></p>
  
  <p>The hiccup with that setup might be trying to reliably get memberships to attribute from the parent organization through those relationships to the individual contacts themselves.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-14T20:34:24.063Z
Answers.Text: I must be missing something from that post, or, once again, I wasn't clear enough on the problem.  From your suggestion, it looks like you are thinking that I have a problem with the data stored in an org record.  The real problem I am having is how to create a cascading flow of hierarchy.  Thus, the problem I'm trying to solve is much more in line with the hiccup you address.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-14T20:54:56.050Z
Answers.Text: I was more thinking the hierarchy would be constructed with contact types and custom relationships e.g. use a relationship "department of/has department" only between contact types organization and department (subtype), and a relationship "team of/has team" between contact types department and team only, etc. Access controls could be set on contact types etc - I just wouldn't know how to deal with membership. Maybe each employee still retains a relationship "employee of/employer" with the parent organization and base the membership on that relationship.
Answers.UserDisplayName: Eli Lisseck
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-14T21:10:12.917Z
Answers.Text: Ahhh ... yes, that could work!  I'll try to test it out tomorrow.  That bit of info was the missing bit that was trying to make my head explode.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-14T22:10:59.230Z
Answers.Text: Agree with Eli. Use a specific Relationship type between each level.  And then if you are using Drupal (always helps to specify your cms in question) then you can build Views that can pull multiple levels in to useful displays, which is something civi isn't that good at currently afaik.
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-04-29T18:11:21.353Z
Answers.Text: Updated link:  https://civicrm.org/blog/mjpforsberg/using-contact-subtypes-for-a-clutter-free-life
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-05-27T14:50:38.850Z
Answers.Text: Still working on getting all of this configured.  (Lots of other things too.)  However, it's looking like this will work.  Marking this answer as accepted.
Answers.UserDisplayName: G H
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-01-14T20:00:43.473Z
Answers.LastActivityDate: 2016-01-14T20:00:43.473Z
Answers.UserDisplayName: Eli Lisseck
Body: <p>I'm trying to figure out how to divide people up and group them organizationally.  Adding each person to an organization and creating a relationship is easy.  However, I need to break them down further than one top level organization.  I'll use the word team for generalization.  Most of my searches have ended up back in the '07 discussion on sub-organizations, and to some degree that's what I need.  However, 9 years later, it still seems unclear.  So, what am I missing?</p>
  
  <p>Org has departments.  Departments have teams.  Teams can have sub-teams.  Each level also has roles, which easily fits into a relationship.  (Org has President, Department has VP, Team has Team Leader and team member, etc.) Each level has it's own set of documents, cases, workflows, etc.  (A new team has a Case with a timeline of "New Team", each team has a goal document, each department has a set of protocol documents, the org has overarching protocol documents, etc.)</p>
  
  <p>Without being able to nest Orgs, or a massive amount of manual adjustment with each change, how do I show that Team Member C, on Team D, which is part of Department G, is an employee of Org?  Also, each contact needs to have a membership to the org.</p>
  
  <p>Confused yet?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-01-15T13:23:10.217Z
Comments.Text: Sorry, as @PeteDNZ noted, I should have stated that this was on top of Wordpress.
Comments.UserDisplayName: G H
Tags: <configuration>
Title: Department/Team/Franchise Setup
ThreadText: # Department/Team/Franchise Setup
  
  (Asked by: username_0 on 2016-01-14)
  
  I'm trying to figure out how to divide people up and group them organizationally. Adding each person to an organization and creating a relationship is easy. However, I need to break them down further than one top level organization. I'll use the word team for generalization. Most of my searches have ended up back in the '07 discussion on sub-organizations, and to some degree that's what I need. However, 9 years later, it still seems unclear. So, what am I missing?
  
  Org has departments. Departments have teams. Teams can have sub-teams. Each level also has roles, which easily fits into a relationship. (Org has President, Department has VP, Team has Team Leader and team member, etc.) Each level has it's own set of documents, cases, workflows, etc. (A new team has a Case with a timeline of "New Team", each team has a goal document, each department has a set of protocol documents, the org has overarching protocol documents, etc.)
  
  Without being able to nest Orgs, or a massive amount of manual adjustment with each change, how do I show that Team Member C, on Team D, which is part of Department G, is an employee of Org? Also, each contact needs to have a membership to the org.
  
  Confused yet?
  
  **Tags:** configuration
  
  > **Comments:**
  > **username_0**: Sorry, as @PeteDNZ noted, I should have stated that this was on top of Wordpress.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-01-14. Score: 1 | Accepted answer
  
  It sounds like departments, teams, and sub-teams could be set up as contact sub-types of the organization contact type, possibly with custom relationships between each that are intuitively named, as described here:
  
  <https://civicrm.org/blogs/mjpforsberg/using-contact-subtypes-clutter-free-life>
  
  The hiccup with that setup might be trying to reliably get memberships to attribute from the parent organization through those relationships to the individual contacts themselves.
  
  > **Comments:**
  > **username_0**: I must be missing something from that post, or, once again, I wasn't clear enough on the problem.  From your suggestion, it looks like you are thinking that I have a problem with the data stored in an org record.  The real problem I am having is how to create a cascading flow of hierarchy.  Thus, the problem I'm trying to solve is much more in line with the hiccup you address.  
  > **username_1**: I was more thinking the hierarchy would be constructed with contact types and custom relationships e.g. use a relationship "department of/has department" only between contact types organization and department (subtype), and a relationship "team of/has team" between contact types department and team only, etc. Access controls could be set on contact types etc - I just wouldn't know how to deal with membership. Maybe each employee still retains a relationship "employee of/employer" with the parent organization and base the membership on that relationship.  
  > **username_0**: Ahhh ... yes, that could work!  I'll try to test it out tomorrow.  That bit of info was the missing bit that was trying to make my head explode.  
  > **username_2**: Agree with Eli. Use a specific Relationship type between each level.  And then if you are using Drupal (always helps to specify your cms in question) then you can build Views that can pull multiple levels in to useful displays, which is something civi isn't that good at currently afaik.  
  > **username_0**: Updated link:  https://civicrm.org/blog/mjpforsberg/using-contact-subtypes-for-a-clutter-free-life  
  > **username_0**: Still working on getting all of this configured.  (Lots of other things too.)  However, it's looking like this will work.  Marking this answer as accepted.  
  
  ---
  
  