In my last blog post about multi-org, I made the case for merging groups and relationships as an elegant solution to the multi-organization data modeling requirements. My thinking boiled down to:

1. Groups represent a relationship between "you" (i.e. one of the owner organizations of that Civi instance) and a contact (i.e. a member, newsletter subscriber, media contact, alumni, etc.).
2. Relationships represent a relationship between 2 external contacts.

So, under multi-org there would be more than one "you" for the first scenario above, and I thought well, let's just piggyback on the existing many-to-many data model we have for relationships. However, this proved too drastic a change to make it into 2.3, so we (I and the core dev team) went back to the drawing board.

We ended up revisiting an old idea that now seemed much more feasible thanks to other changes going into 2.3. Namely, we looked into linking groups with organization contacts to represent internal orgs that make your multi-org hierarchy. The group would hold the child groups and contacts (thanks to group nesting) of each org or sub-org and the linked org contact record would hold the metadata about each org or sub-org (things like where it's located, the path to its logo graphic, its name, etc.). This is mostly used when branding content such as mailings in CiviMail. We want to be able to send the same e-mail to several orgs at once but have it branded by the most appropriate org for each recipient.

Our implementation plan is covered by the following issues in Jira (our bug tracker):

• CRM-4609 - Create a new permission called "Administer multiple organizations"
• CRM-4610 - Allow connecting Organization contacts to Groups for multi-org support
• CRM-4611 - Sites in multi-site need the ability to specify the org/group pair that they represent
• CRM-4612 - Create a lookup function that returns which group/org pairs a user is responsible for
• CRM-4613 - Add a new requirement that all new contacts must be added to a group
• CRM-4614 - Add a new requirement that all new groups must have a parent group
• CRM-4615 - Add multi-org token resolution features to CiviMail

Breaking that down a bit, we will create a new permission type that allows users with that permission to link groups and org contacts (thus creating new internal orgs in the multi-org hierarchy). Obviously you don't want to give this permission to very many users. We will then create a new link table between org contacts and groups. So, for example, one of our top-level national orgs is U.S. PIRG. There will be a contact record for them and a group. Underneath that group will be other orgs and groups. The child orgs will be State PIRGs (like CoPIRG, MASSPIRG, CALPIRG, etc.). From there we will hook into the already-begun multi-site work and specify that each org/group pair has a site that represents it. Since typically you have a unique URL or an entirely separate website for each org in your hierarchy. Then we will create a lookup function to determine, for any given user, what group/org pair(s) are they associated with? So your uber-admin will be associated with all of them. An employee at CALPIRG would only be associated with CALPIRG, and a U.S. PIRG user, depending on their role, might just return U.S. PIRG is or return U.S. PIRG and all child orgs too (these may be explicitly returned or inherited, I'm not sure which way we'll go just yet). The next 2 requirements for contacts and groups to always have a group or parent (respectively) make sure that we don't have orphan records floating around in the system. Since all permissioning will be based on these orgs and groups, we need to make sure every record in the system fits into the hierarchy somewhere. This will have sane defaults for each user (the top-level org/group they are associated with in most cases). The last feature will allow CiviMail to resolve which org in the hierarchy it should use for any given mailing recipient when inserting values for {org.*} tokens (i.e. {org.name}, {org.state}, {org.director.first_name}, etc.). You can see more implementation details for each of these by clicking on the links above.

So, for anyone who is interested in multi-org support in CiviCRM, please review this plan and let us know whether or not it will fit your needs. We can't accommodate every single use case in the first release of multi-org (CiviCRM 2.3), but we would like to know how close we've come. And, if there are simple tweaks we can make to our implementation that make the difference for your use cases, then we'd love to accommodate you.

Please leave comments and questions below.