Allowing contacts of contacts?

Question

Background

We're a membership association for music groups, and are in the process of building our new website, using Civi as both the CRM and for some of the functionality, events etc., of the website (along with Drupal).

Challenge

We would like to try to find a way (in the future) to offer group management tools (e.g. simple contact lists, civicontribute for fees and events etc.) to our members themselves.

I don't think that this is currently possible with Civi, as it would need two levels of data structure, i.e...

1. Our CiviCRM/website interface: organisations with contacts, payment processes and membership management etc.

2. Members' CiviCRM/website interface: THEIR own contacts database, THEIR own payment processes for THEIR own membership subscriptions etc.

..but I wondered if anyone has ever tried or thoguht about trying something similar?

Apologies if this is a stupid question, but I'm relatively new to Civi, so not sure what whizzy-amazing functionality might be possible.

Answer 1

Evan from IMBA here. Sorry for replying in a new answer, I don't have the required 50 points of reputation to comment in reply specifically to Lizz Trudeau's answer. I just watched the video Jason (my predecessor) gave at CiviCon 2012, and it gives a really solid overview of how we've tackled this and for the most part we're still set up this way. We've made improvements and enhancements along the way as new features become available in Civi, but the bones of what we're doing are the same. There are loads of things to consider when deciding on a tiered implementation, and a couple of good ideas have been thrown out already. Here's my take on what we've done vs. other solutions presented:

1. CiviCRM Multi-Site: for us at the time, we didn't have the need or capacity as an organization to support this structure. In our revenue share model, all membership funds are processed and collected by the parent organization and then dispersed quarterly to the chapters. We could certainly set up the payment processors, etc. for each chapter but restricting access to change settings like this would have been an issue. This remains a viable option for us in the future, as our chapters grow in function and capacity. Particularly if we enable a Drupal multi-site structure where IMBA offers chapter website hosting as subdomains of the main site. It's on the table for consideration in 2016.
2. Relationship Permissions as ACLs has my attention. Our method of using a multi-select custom data field to track multiple contact-to-chapter relationships works pretty well, but can be a little cumbersome and finicky when importing large lists into Civi and a few other tasks. Using relationships as ACLs could be a better way of handling this, but might also trade one set of challenges for another. I think if we were starting from the ground up, this would be a solution we would strongly consider, right now making the change seems rather daunting. We would still need to use custom data fields to track the revenue share component of contributions, to the best of my knowledge.
3. Using Custom Data Fields to Create Groups and ACLs has worked pretty well for us over the years, has been scalable through multiple Civi updates starting with 3.x all the way to 4.6. We've built some custom code to support it here and there such as increasing efficiency in the back office during data entry, but as Jason said in the video it's largely out of the box functionality. What it doesn't give our chapter admins permission to do is use their own payment processors, access to CiviEvent, etc. There are some pain points but largely it works well. In some ways it's a similar approach to the Relationships, and I think each would have their own challenges and strengths. Co-branding with our chapters is super important, and using the custom fields allows us to pull that data in searches, reports, and other lists which are then sent to vendors for doing membership fulfillment, renewal messaging, and even some region- or chapter-based variable content in our quarterly print magazine for instance. We're also making some changes to these custom fields to (hopefully) enable us to place custom tokens into email messaging as well.

Challenges we face:

1. Better signup UI: Right now we still have just one user workflow on the /join page, and I'd like to revamp this so we send renewing members directly to a contribution page for their specific chapter, rather than sending them through the "join" workflow which requires them to select their local chapter each time. This should be possible using the custom data fields as tokens and contact hashes. We now have over 180 chapters, and having a giant dropdown select is not a good UI solution. We've got some ideas in the works with Fuzion that will address the signup process and provide a better experience for visitors, but still capture revenue share data as needed.
2. Living with your neighbor's dirty laundry: this remains a bit of an issue with certain features of Civi not easily quarantined via ACLs. That all users can see the entire "From" email address list is one of these things, although minor. A larger one is that our chapters would like us to support Event Registration for their local events, but enabling those users access to CiviEvent grants them access to all other events in the system, not just their own. This may have changed since last I looked, but it has been a sticking point of opening up this feature to our chapters.
3. Growing our chapter's contact lists: Each "CHAPTER All" ACL group is a smart group based on that chapter's name being in the multi-select custom field. Each chapter's territory is defined by postal code. When a chapter is integrated, we import their list of contacts and also search out any existing contacts in their zip code territory, and add this chapter to that custom field for all these contacts. So the only time we place existing contacts in a chapter's partition (share back contacts from the main IMBA DB) is when the chapter is integrated. As new contacts come to the main IMBA database, they're not being actively shared back the appropriate chapter's partition. This was a conscience decision made years ago, but one that has recently changed. We have an extension that updates a contact's region based on zip code, it will be more challenging to update the chapter affiliation of a contact as each contact can be visible to multiple chapters. (NOTE: a contact can be associated with a chapter outside of their zip code by opting in, attending a fundraiser and signing up for email newsletters is an example of this)
4. Accommodating members who wish to join multiple chapters: Pretty self-explanatory here. Some of our members want to belong to more than one chapter. Summer home, favorite vacation spots, etc. Our preference would be to NOT implement 180+ membership types, so we're still brainstorming ideas for a solution. And the reality is, right now this challenge lies in sorting out the business rules and requirements, not in database or CRM limitations.

That's just an overview from our perspective, I'm sure I could ramble on and on about everything we've done that's worked and hasn't but I really should get back to testing some new functionality. Feel free to ping me with questions, I hope I helped.

Answer 2

Two ideas come to mind:

1. If you're more of a federated organization where it would be natural for your members' contacts to be in your database, you could set up a multisite installation.

2. You could offer an easy way for them to launch their own CiviCRM. You might manage them using Aegir, or if that's more responsibility than you want, you could even just build an extension that makes some common configuration changes that your members would want. (My company did this for the National Democratic Institute to provide easy-to-start CiviCRM sites for political parties in emerging democracies.)

Answer 3

It will depend on how much of the setting up you (a superadmin) will take care of, eg will you add 'their' payment processors and perhaps set up their Membership pages, to avoid the risk of 'them' doing that step themselves and setting an incorrect payment processor on their membership page etc.

Multisite does add the ability/complexity so that each sub-org (domain) has its 'own' membership pages and payment processors, which is good. But that also may mean higher level training of sub-org Admins than is ideal.

There is another approach which can get you a long way towards this without multisite. Eg, using the "Relationship Permissions as ACLs" extension together with Webform you can easily cook up a system so that your sub-organisations can sign up people who then are added to their 'container'. And hence your sub-org admins can access CiviCRM and be restricted (in most situations) to only accessing their contacts.

This ACL approach allows for multiple 'cascading' levels.

Answer 4

I recall https://www.imba.com/ having this setup as a chapter program. I saw information about this a while back at http://vimeo.com/channels/civiconsf2012/40545511

Answer 5

Future First has a portal where their members can log in, view, edit, email, and search by their contacts.

Most of this can be achieved by cleverly configuring Drupal. Happy to supply more details on request - message me!

Answer 6

Depending on how much functionality you want to offer your members, you may be able to construct your own Views and Webforms to serve their needs.