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:
- 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.).
- 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):
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.
Comments
Thinking about this from the perspective of political parties, it might be worthwhile to be able to have no orphans as a constraint for more than one level of organization. So, all voters must be assigned to a riding/district for federal offices as well as for provincial offices. There can be no orphans at either level.
My concern is less with CiviMail than with delegating permissions to those responsible for a province/state or for a riding/district. Everything you write seems compatible with that, but I'm unclear if there are hidden issues or interactions.
Cheers,
Joe
Is that you can "type" the relation between two contacts (eg this one is the president of that org, this one is a member), but the relationship between a group and a contact is a boolean (either you belong or you don't, but you can't specify that one belong as a board member while the other is a volunter.
X+
To extend this idea a bit, a common use case for multi-level orgs is that the sub-orgs may have boards/staff, who have replicated roles/permissions similiar to what has been worked out for the NS Greens. For example, all local groups have someone responsible for memberships, another responsible for money, another responsible for volunteers, another responsible for events, another for newsletters & communications.
And being able to search/filter on relationships as easily as it's done on the groups today, and hiding the group away and keep them for technical stuff ?
2.x ? ;)
X+
While it is true that the current design is such that relationships specify a type and group membership does not, it seems unreasonable to maintain this constraint. To overcome this constraint we will have to merge the concepts of Groups and Organizations. This is the next logical step and one that we are experiencing demand for.
We've been doing quite a bit of work around multi-org recently, in particular where there is a Country broken down into States and the States have a range of Branches, which members can transfer between from time to time, but with only one paid annual membership for the Country.
We have run headlong into the challenge of where to use memberships, groups and relationships and ultimately the binary nature of groups, their lack of connection to a target contact and the requirement to have a separate Membership Type for each organisation that people or branches could become a true "Member" of, meant that we have moved away from memberships (except for Country level) and groups, and used relationships because:
(a) One "Relationship Type" can be used to create a "Member of" relationship between individuals and different Branches, with another to create a "Branch of" relationship between many branches and different States;
(b) You can also have a "President of", "Treasurer of", "Secretary of" relationship between individuals and many different Branches and/or States rather than just "in" or "out" of a group;
(c) You can set a start and end date for relationships (while groups store this based on the date you add/remove, but from recollection you can't change it through the GUI)
HOWEVER, we really miss the fact that relationships aren't hierarchical so while we might say a person has a relationship of "Member of" a branch, each branch has a relationship "Branch of" to a State, and each State has a relationship of "Branch of" to the Country, we can't find all the people with a particular relationship to the Branches in a State like we could if we used Memberships to create the link between the Branch and the State (with a separate Membership Type for each State and a "Member of" Relationship Type inheriting membership) or hierarchical groups (with each State being a sub-group of Country, each Branch being a sub-group of a State and each branch member being in the Branch sub-group, but with no way to identify who is "President of" the branch)
The above sounds like it could help with some of these issues, but it would also help if:
(a) You could create a single Membership Type like "Ordinary Member" that, like a Relationship, can operate between individuals and multiple organisations that have a particular relationship or are in a particular group (such as Branches); and
(b) on an unrelated topic, you could create sets of membership periods and fees for each Membership Type, like 1 year $100, 2 years $190 or 3 years $270