E-mail
Note: If you know how any of the commercial systems (SalesForce, SugarCRM, Kintera, Convio, GetActive) handle this issue, please describe it briefly in the comments.
Summary
CiviCRM currently does not have a very developed model for handling multiple organizations. We need to extend this model, allowing better integration of groups and organizations.
USPIRG Use Case
We need to be able to create reports, emails and manage properties for any of the organizations from USPIRG down to a sub-organization in a state PIRG. We also compile "lists" for the purposes of sending emails and the like, which currently dovetail with the "Groups" feature in CiviCRM. (More about this under "Model.")
USPIRG and all the state PIRG's/Environment organizations have their own contacts and management. Each PIRG/Environment organization has sub-organizations as well. The affiliated organizations need to be separated appropriately in CiviCRM. That is, we need to have a top-down hierarchy of all our organizations, so that we can divide up viewing, editing, and actions for a larger group, statistics, etc., into smaller organization-by-organization pieces, as well as still allowing aggregate actions for the Colorado Organizations as well as USPIRG.
For instance, our Colorado constituency consists of CoPIRG and Environment Colorado, and several affiliated organizations. We need to be able to:
Send a mailing from the COPIRG organization and and still be able to send different messages to different sub-organization's constituents, as well as create reports for the results for the different constituent bases for each sub-organization.
We also need to be able to do similar actions at a national level with USPIRG.
Also, we need to be able to allow multiple "parents" for a given organization/group (the two should be synonymous in our model). For instance, we may have a group of staff who graduated college in '07, and a group of staff who do internet organizing. We might want to combine the two, and the resulting group would have both these as parents.
Nested Groups Model
The current CiviCRM organization model assumes a single central organization, and this is associated with the instance of CiviCRM.
As a partial workaround for this problem, the Code for Change team has implemented a nested group model, which we hope will be part of CiviCRM 2.0. (See Proposed Nestable Groups implementation.)
This model allows groups to be represented hierarchically, i.e. a group can have parents and children. Organizations are then members of groups, allowing an indirect parent-child relationship between organizations.
Model
Proposed model is a hierarchy of organizations that allows for the following:
- Contact information for each organization.
- Reporting of statistics for organizations.
- Aggregation, an organization should be able to show data for sub-organizations.
- A Permissioning System. Options:
1. Organization administrators can view sub-organizations by default, and super-orgs only if permissions allow.
2. Organization administrators should not be able to view sub-organizations by default. - Interaction between CiviMail and organizations. Mailings can be sent by Organizations and reports created based on Organization or super/sub-groups.
- Currently mailings can be sent on an organization basis, but only indirectly (see implementation).
- Allows tokens to be replaced for a recipient based on the organization they belong to when a mailing is sent to multiple organizations by a parent organization.
- Searchability.
- This interacts weakly with the present model.
- Presently, searching for members of a group, or for groups that contain an organization is possible.
- We need to search for all organization contacts with matching criteria, an option not currently offered owing to the separation of groups and orgs.
The structure of the hierarchy is as follows:
- An umbrella organization exists at the national level (in our case, USPIRG). It has, say, one hundred and some organizations at the state level.
- Each of these state-level orgs will be combined into a group entity that is not affiliated with a specific organization, but will have all the features and trimmings of one. So for example, Environment Colorado (which is under the PIRG umbrella) and Colorado PIRG will be combined, along with one or two other groups, into the Colorado group. We want this to be able to agglomerate statistics as necessary.
- These may have subgroups which perform functions for mailing lists and other functions. For some purposes they will need to be treated as organizations. For instance, they may have some sort of contact information or statistics that would be associated with an organization.
Permissions
Naturally, any multi-organizational model will necessitate some sort of permissioning system. For our use case, we'd like parent orgs to be able to view contacts, mailings, statistics, etc. for child orgs by default, though we'd like some flexibility for changing this on an individual basis.
In the above scenario, where we have a list of organizers, a list of '07 college grads, and a combined list of the intersection of the two, one of the parent orgs might need to be limited in its ability to see the child group. In other words, the permissioning system needs to account for several situations:
1. Parent organization(s) can view all aspects of children, but children are denied access to the parent(s).
2. Parent org(s) are prohibited from viewing some aspects of children, and the reverse is true.
3. Possibly, we may want a peer relationship with some things hidden and others not. (See JoeMurray's comment below.)
The model will either be multi-parent or single-parent. The latter would have a tree hierarchy of groups, allowing simple cascading permissions determination. However, we would want to make modifications to this for the sake of distinguishing 1 & 2.
If it's multi-parent, we would have a graph-tree hybrid, where cycles are prohibited. It would be somewhat more difficult but not impossible to implement this.
For case-by-case permission setting, we also want some sort of user interface, so that a person belonging to a parent org can set permissions for a child.
Proposed Implementation
Options:
1. Link the organization's contacts and organization groups so they are aware of each other and pull data in both directions
2. allow organization contacts to have members and sub-groups (i.e. give them the properties of groups)
a. This option will almost certainly not be used.
3. allow groups to also be organization contacts (i.e. give them the properties of organization contacts)
Implementation
Group as member of a Group?
One possible change is to allow groups to belong to groups, rather than having the separate parent-child relationship.
Organization can be parent of group
Instead of the organization being contained in a group, we might consider making it work the other way around. This would be a bit more intuitive.
needs to access the group data
Consider the possibilities for allowing an organization contact to access the group data, such as who the members are etc.
Owner organization for a group
Consider giving the groups knowledge of what organization they are for. That way, functions operating through a group can easily be extended for organization-related features.
Primary organization?
Similar to the above... allow groups to contain multiple organization contacts, one of which is primary for the group. Perhaps have a custom field on the group stating which that is.
New Group Type: Organization
Simply make organizations another type of group.
Attach custom fields to groups, such as Congressional District. User as an owner of a group.
Permissions
For implementing permissions, there are several options:
- Use and extend the present domain system to fit our needs.
- Use and extend the present ACL system to fit our needs.
- Some combination of the two.
