The Public Interest Network (U.S. PIRG, et. al.)

These use cases were written by Wes Morgan and are typical of The Public Interest Network will use CiviCRM in a multi-org environment. Each of the sub-headings below will categorize the use cases based on the type of usage.

Administration

1. I'm installing CiviCRM for U.S. PIRG, which consists of a national organization and a couple dozen state orgs (State PIRGs). I need to model this organizational hierarchy in the system in order to properly setup permissioning, data siloing, and automated branding such as CiviMail token replacement. It is also crucial for having the data structure in the system accurately reflect reality. For example, a particular individual contact needs to be associated with the org(s) that he or she gave money to, volunteered with, signed up to get e-mails from, etc. and within that org they should be further categorizable by staff working in that state (into groups, ideally, since that's the most intuitive). Some of this I could implement with custom ACL hooks and relationships, but then my users have to use relationships instead of the much more intuitive and efficient groups system.

1. I'm setting up a new issue advocate user in a State PIRG who needs the same permissions as other issue advocates in that state. I'd like to be able to just add her to a specific group of users so that she inherits those same permissions on the same set of contacts and modules. I'd also like to see, via the same process, who else is in that group so I can confirm that everyone who is in there should be in there (i.e. people who have left staff are removed, etc.).

Online Organizing

1. The U.S. PIRG online organizer wants to send out an e-mail to the national U.S. PIRG list and several of the State PIRG lists all at once. He doesn't have time to set this up as a separate e-mail for each org, but he needs the system to brand each e-mail according to the org that each recipient is affiliated with. CiviMail needs to be able to reliably look up this information for each recipient (group) and replace the {org.logo}, {org.name}, {org.director_name}, etc. tokens with the appropriate information pulled from an Organization contact record representing the recipient's affiliated org. Since CiviMail operates on groups, it would be most convenient if this contact<->org affiliation were already represented via the Groups system in CiviCRM.

Reporting

1. The director of a State PIRG wants to see how her online organizing list is performing this quarter so she accesses the Quarterly Online Organizing Report in CiviCRM and runs it. Since her permissions are full access to her State PIRG but no others, the report should automatically just run on her Online Activists group. It's much simpler for her when she can see and report that the set of people this report encompasses are the same set of people she can quickly access for other purposes by pulling up the Online Activists group from the Groups system, and that she could trace the connection to her organization via the same system. This would be much less intuitive if it relied on a relationship instead, especially if one of the affiliations (i.e. Online Activists) was a group, and one of them was a relationship (i.e. the affiliation with her State PIRG as an org).

1. The national director of U.S. PIRG wants to see how his entire network's online organizing lists are performing this quarter taken together as an aggregate whole. He should be able to access the same Quarterly Online Organizing Report in CiviCRM and have the ability to choose how broadly to apply it when it's run. If he selects the (smart) group "U.S. PIRG and all State PIRGs" then the report should do what he wants. He should also be able to see, via the same list from where he selected "U.S. PIRG and all State PIRGs", the list of all the State PIRGs and their sub-groups (i.e. "Online Activists", "Alumni", "Members", "Newsletter Subscribers", etc.).