Implementing support for multiple organizations with hierarchy is one of the main themes of the phase 2 part of the CiviCRM / The Public Interest Network (PIN) project. PIN has a fairly complex structure. It is a federation of organizations which include US PIRG, Environment America and others. It is made up the National PIN organization and has a number of child organizations at the National Level. One of them is Environment America (EA). The org chart of EA can be found here.

EA National has a few groups at the national level (EA National Members, All Online Activists, Other Aggregate Groups). It also has a lot of sub organizations ( EA California, EA Colorado and approx 30 other state organizations). Each State Chapter has a few groups at the state level (EA California Members, EA California Activists etc). Each State also has sub organizations for geographic regions (EA Bay Area, EA LA Area, EA Northern California etc). These regions could have more sub organizations ( EA San Francisco, EA UC Berkeley, EA Stanford etc). So basically we have a 4 level deep organization nesting level with groups at each level. At any intermediate level there can be Aggregate groups (i.e. All Online Activists, All Online Activists in EA California, All Online Activists in EA Bay Area)

From a permissioning perspective, there are admins at all levels (with various permissioning granularities needed at each level). You also have permissioning attached to the aggregate groups, i.e. you want a few folks to be able to see/send email to contacts in online activists only (and not any other groups that they belong to).

The green party of NZ implementation had the "voter feature" as a defining characteristic. Thus a contact could belong to one and only one voting district and it was a relatively nice tree hierarchy (for the most part). This made the ACL implementation pretty simple and quite efficient (check the blog post here and here for details) The PIN case on the other hand does not fit this model. A contact could belong to multiple organizations across the hierarchy and also to a few different aggregate groups. Permissioned users could also have access to different sets of the hierarchy based on various factors, i.e. we cannot model the permissioning relationship as a simple set of easily computable math equations

There are two potential ways we can model the hierarchy and the permissioning.

• Model everything as a group including organizations. This uses the hierarchical group concept (introduced in 2.1) and basically lays out the structure as it appears on the org chart. The permissioning model remains the same, i.e. at the group level and users will have read/write access to one or more groups. This creates a large number of static (and hierarchical groups). For the EA case, if we assume a 2 level hierarchy with 5 groups at each level, this creates 180-200 groups (depending on number of aggregate groups). If PIN has 10 different organizations like EA, this results in 2000 groups (assuming EA is a good sample)
• We could also model everything as a relationship. So organizations are modeled as CiviCRM organizations and a contact belongs to an organization using a descriptive relationship type (like "member of" or "online activist for"). The organization hierarchy is also modeled as a relationship using a relationship type "Child Org / Parent Org". Permissioning is now a combination of group based permissioning and relationship based permissioning. An admin with permissioning for all contacts belonging to a org X, basically queries the relationship table to get all contacts that have a relationship with org X. If org X is a parent org, we need to include all the children orgs as part of the above query. All the "contacts" belonging to an organization are smart groups (based on relationship type id and organization id). This reduces the number of groups involved since all organization groups are now smart groups. We could make it even smarter if the system knows about the relationship type and can create a smart group on the fly (i.e. similar to tokenized smart groups which we've talked about). However to improve performance, we've started caching smart group members – so from a DB perspective, we probably have the same number of groups.

Either of the above solutions don't seem to be very scalable (IMO). Our next steps will be to construct a reasonable data set for the EA org chart and see performance of various mysql queries for the above two models. There are a fair number of usability / scalability issues we'll need to tackle to address this in a complete manner