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?

  • Sorry, as @PeteDNZ noted, I should have stated that this was on top of Wordpress.
    – G H
    Commented Jan 15, 2016 at 13:23

1 Answer 1


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:


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.

  • 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.
    – G H
    Commented Jan 14, 2016 at 20:34
  • 2
    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. Commented Jan 14, 2016 at 20:54
  • 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.
    – G H
    Commented Jan 14, 2016 at 21:10
  • 1
    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.
    – petednz - fuzion
    Commented Jan 14, 2016 at 22:10
  • Updated link: civicrm.org/blog/mjpforsberg/…
    – G H
    Commented Apr 29, 2016 at 18:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.