Answers.Body: <p>Further to Jon's response, you must be seeing a reason for not making them both organizations, and setting up a relationship between them.</p>
  
  <p>Given the importance of getting this right, I suggest that you try each of your methods and see what works best for you. </p>
  
  <p>The <a href="https://civicrm.org/demo" rel="nofollow" title="CiviCRM Demo">demos</a> are a good starting place, but you may want to create sandbox instances as the demos get cleared out periodically and you'll lose your work. Another disadvantage of the demos is you can't create additional logins to see how a non-admin user will see the system.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-08T19:26:51.560Z
Answers.Text: I will probably stick to making them both organizations, i just could not see if there were advantages to others. 
  
  Also, I did test this in cividemo and each idea seemed to work except because i am new to Civi, I am not sure if there is something I am overlooking
Answers.UserDisplayName: Anne Douglass
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-08T19:13:39.333Z
Answers.LastActivityDate: 2015-07-08T19:13:39.333Z
Answers.UserDisplayName: Sanjay Jain
Answers.Body: <p>There's no reason not to make all of your entities Organizations (using Contact Subtypes), since that's what they are.  CiviCRM doesn't have a built-in "contact hierarchy".  The hierarchy is implemented through relationships, and you can define your relationships however you like.</p>
  
  <p>I'd read the documentation on <a href="http://gitbook.civicrm.org/organising-your-data/contacts.html" rel="nofollow">contact subtypes</a> and <a href="http://gitbook.civicrm.org/organising-your-data/relationships.html" rel="nofollow">relationships</a> and see if that helps to answer your question as well.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-07-08T18:38:43.067Z
Answers.LastActivityDate: 2015-07-08T18:38:43.067Z
Answers.UserDisplayName: Jon G - Megaphone Tech
Body: <p>I am new to Civi (I started working for a company that is using it). I actually started this question in Civi community and was guided here.</p>
  
  <p>Our company currently uses civi to track our corporate membership. We want to import our clients who are schools and districts, as well. Except we have a concern about how to organize schools and districts (Schools come to us as projects from the district level and it is our end goal to use civicase to monitor our projects).</p>
  
  <p>One of our plans is to import schools as individuals and create a Contact Type properly identifying them as schools and import Districts as companies.</p>
  
  <p>Another suggestion made was importing both as companies and properly identifying the Contact Type in this way (ie, schools, districts, corporate)</p>
  
  <p>A third idea was to import schools as companies and districts as a household. But I am not sure how the relationships will work between these.</p>
  
  <p>As someone new to civi, it is difficult to see the advantages and drawbacks of each option. On top of which, occasionally our projects names are different to the school name and we keep record of both.</p>
  
  <p>Any input or advice would be greatly appreciated! </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-07-10T02:27:11.973Z
Comments.Text: I agree with comments about doing them as Org sub-types and use Relationships. If you actually need some hierarchy eg so that officers at the District Level can access data about 'their' schools, but not see other district's schools then you may want to take a look at our extension here which does this well. https://civicrm.org/extensions/relationship-permissions-acls. We use it in scenarios of schools/students and also churches/parishioners so it can go global/national/regional/local and at each stage ensure people at one level can access contacts at lower (more local) levels.
Comments.UserDisplayName: petednz - fuzion
Tags: <contacts>
Title: Need help understanding contacts hierarchy
ThreadText: # Need help understanding contacts hierarchy
  
  (Asked by: username_0 on 2015-07-08)
  
  I am new to Civi (I started working for a company that is using it). I actually started this question in Civi community and was guided here.
  
  Our company currently uses civi to track our corporate membership. We want to import our clients who are schools and districts, as well. Except we have a concern about how to organize schools and districts (Schools come to us as projects from the district level and it is our end goal to use civicase to monitor our projects).
  
  One of our plans is to import schools as individuals and create a Contact Type properly identifying them as schools and import Districts as companies.
  
  Another suggestion made was importing both as companies and properly identifying the Contact Type in this way (ie, schools, districts, corporate)
  
  A third idea was to import schools as companies and districts as a household. But I am not sure how the relationships will work between these.
  
  As someone new to civi, it is difficult to see the advantages and drawbacks of each option. On top of which, occasionally our projects names are different to the school name and we keep record of both.
  
  Any input or advice would be greatly appreciated!
  
  **Tags:** contacts
  
  > **Comments:**
  > **username_1**: I agree with comments about doing them as Org sub-types and use Relationships. If you actually need some hierarchy eg so that officers at the District Level can access data about 'their' schools, but not see other district's schools then you may want to take a look at our extension here which does this well. https://civicrm.org/extensions/relationship-permissions-acls. We use it in scenarios of schools/students and also churches/parishioners so it can go global/national/regional/local and at each stage ensure people at one level can access contacts at lower (more local) levels.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2015-07-08. Score: 2
  
  Further to Jon's response, you must be seeing a reason for not making them both organizations, and setting up a relationship between them.
  
  Given the importance of getting this right, I suggest that you try each of your methods and see what works best for you.
  
  The [demos](https://civicrm.org/demo "CiviCRM Demo") are a good starting place, but you may want to create sandbox instances as the demos get cleared out periodically and you'll lose your work. Another disadvantage of the demos is you can't create additional logins to see how a non-admin user will see the system.
  
  > **Comments:**
  > **username_0**: I will probably stick to making them both organizations, i just could not see if there were advantages to others.   Also, I did test this in cividemo and each idea seemed to work except because i am new to Civi, I am not sure if there is something I am overlooking  
  
  ---
  
  ### Answer by username_3 on 2015-07-08. Score: 2
  
  There's no reason not to make all of your entities Organizations (using Contact Subtypes), since that's what they are. CiviCRM doesn't have a built-in "contact hierarchy". The hierarchy is implemented through relationships, and you can define your relationships however you like.
  
  I'd read the documentation on [contact subtypes](http://gitbook.civicrm.org/organising-your-data/contacts.html) and [relationships](http://gitbook.civicrm.org/organising-your-data/relationships.html) and see if that helps to answer your question as well.
  
  
  ---
  
  