Answers.Body: <p>Two ideas come to mind:</p>
  
  <ol>
  <li><p>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 <a href="http://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+Installation" rel="nofollow">multisite installation</a>.</p></li>
  <li><p>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.)</p></li>
  </ol>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-10T15:20:36.060Z
Answers.LastActivityDate: 2015-08-10T15:20:36.060Z
Answers.UserDisplayName: Andie Hunt
Answers.Body: <p>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.</p>
  
  <p>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.</p>
  
  <p>There is another approach which can get you a long way towards this without multisite. Eg, using the "<a href="http://www.fuzion.co.nz/relationship-permissions-acls" rel="nofollow">Relationship Permissions as ACLs</a>" 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.</p>
  
  <p>This ACL approach allows for multiple 'cascading' levels.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-10T20:44:48.667Z
Answers.LastActivityDate: 2015-08-10T20:44:48.667Z
Answers.UserDisplayName: petednz - fuzion
Answers.Body: <p>I recall <a href="https://www.imba.com/" rel="nofollow">https://www.imba.com/</a> having this setup as a chapter program. I saw information about this a while back at <a href="http://vimeo.com/channels/civiconsf2012/40545511" rel="nofollow">http://vimeo.com/channels/civiconsf2012/40545511</a> </p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-13T19:16:07.303Z
Answers.LastActivityDate: 2015-08-13T19:16:07.303Z
Answers.UserDisplayName: Lizz Trudeau
Answers.Body: <p>Future First has a portal where their members can log in, view, edit, email, and search by their contacts.</p>
  
  <p>Most of this can be achieved by cleverly configuring Drupal. Happy to supply more details on request - message me!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-16T20:13:54.557Z
Answers.Text: John - can you flesh this out for others benefits? What is providing the ACL? And is the rest essentially Views and Webforms?
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-16T13:17:28.480Z
Answers.LastActivityDate: 2015-08-16T13:17:28.480Z
Answers.UserDisplayName: JohnFF
Answers.Body: <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-10T18:34:11.420Z
Answers.LastActivityDate: 2015-08-10T18:34:11.420Z
Answers.UserDisplayName: Coleman
Answers.Body: <p>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:</p>
  
  <ol>
  <li><strong>CiviCRM Multi-Site:</strong> 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.</li>
  <li><strong>Relationship Permissions as ACLs</strong> 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.</li>
  <li><strong>Using Custom Data Fields to Create Groups and ACLs</strong> 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.</li>
  </ol>
  
  <p>Challenges we face:</p>
  
  <ol>
  <li><strong>Better signup UI:</strong> 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.</li>
  <li><strong>Living with your neighbor's dirty laundry:</strong> 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.</li>
  <li><strong>Growing our chapter's contact lists:</strong> 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. <em>(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)</em></li>
  <li><strong>Accommodating members who wish to join multiple chapters:</strong> 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. </li>
  </ol>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-14T20:18:51.867Z
Answers.Text: Evan. Thank you for such a fullsome response
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-14T21:15:14.673Z
Answers.Text: Of course, Pete. I'd like to add that IMBA supports a full-time person who manages the database and CiviCRM. I rely entirely on contractors to do dev work, my role being staff education, configuration, new feature ideas, etc. It's super important to have someone who's a champion of your CRM solution, that knows it's quirks and power, and can help staff with usability questions. When Jason transitioned out of the role I'm in and before I came on board, there was a disconnect here and when I came on I could tell the staff was frustrated. Having a resource in the office has been crucial.
Answers.UserDisplayName: Evan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-07T17:11:50.483Z
Answers.Text: Thanks very much for your response (and to the rest of you), really helpful in helping us to get a running start and avoid some pitfalls!
Answers.UserDisplayName: Ollie M
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-14T18:52:49.337Z
Answers.LastActivityDate: 2015-08-14T21:03:02.430Z
Answers.LastEditDate: 2015-08-14T21:03:02.430Z
Answers.UserDisplayName: Evan
Body: <p><strong>Background</strong> </p>
  
  <p>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).</p>
  
  <p><strong>Challenge</strong></p>
  
  <p>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 <em>themselves</em>.</p>
  
  <p>I don't think that this is currently possible with Civi, as it would need two levels of data structure, i.e...</p>
  
  <ol>
  <li><p>Our CiviCRM/website interface: organisations with contacts, payment processes and membership management etc.</p></li>
  <li><p>Members' CiviCRM/website interface: THEIR own contacts database, THEIR own payment processes for THEIR own membership subscriptions etc.</p></li>
  </ol>
  
  <p>..but I wondered if anyone has ever tried or thoguht about trying something similar?</p>
  
  <p>Apologies if this is a stupid question, but I'm relatively new to Civi, so not sure what whizzy-amazing functionality might be possible.</p>
  
Tags: <civicontribute><drupal><civimember><acl>
Title: Allowing contacts of contacts?
ThreadText: # Allowing contacts of contacts?
  
  (Asked by: username_0 on 2015-08-10)
  
  **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.
  
  **Tags:** civicontribute, drupal, civimember, acl
  
  
  ---
  
  ## 6 answers
  
  ### Answer by username_6 on 2015-08-14. Score: 5 | Accepted answer
  
  username_6 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 username_3'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 username_2 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.
  
  > **Comments:**
  > **username_2**: username_6. Thank you for such a fullsome response  
  > **username_6**: Of course, Pete. I'd like to add that IMBA supports a full-time person who manages the database and CiviCRM. I rely entirely on contractors to do dev work, my role being staff education, configuration, new feature ideas, etc. It's super important to have someone who's a champion of your CRM solution, that knows it's quirks and power, and can help staff with usability questions. When Jason transitioned out of the role I'm in and before I came on board, there was a disconnect here and when I came on I could tell the staff was frustrated. Having a resource in the office has been crucial.  
  > **username_0**: Thanks very much for your response (and to the rest of you), really helpful in helping us to get a running start and avoid some pitfalls!  
  
  ---
  
  ### Answer by username_1 on 2015-08-10. Score: 4
  
  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](http://wiki.civicrm.org/confluence/display/CRMDOC/Multi+Site+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 by username_2 on 2015-08-10. Score: 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](http://www.username_2.co.nz/relationship-permissions-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 by username_3 on 2015-08-13. Score: 1
  
  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 by username_4 on 2015-08-16. Score: 1
  
  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!
  
  > **Comments:**
  > **username_2**: John - can you flesh this out for others benefits? What is providing the ACL? And is the rest essentially Views and Webforms?  
  
  ---
  
  ### Answer by username_5 on 2015-08-10. Score: 0
  
  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.
  
  
  ---
  
  