Opublikowane
2013-11-28 06:22
India has over 3.3 million registered non-profits (one for every 400 people!), many of which are growing and looking for better solutions to manage their fundraising efforts. There is an immense and exciting opportunity at hand.
My team works closely with several non-profits that use CiviCRM in India, of which some have an international presence. Over the last six months we have had the opportunity to introduce CiviCRM to many other non-profits, who were very impressed by the wide range of functionalities already built into this affordable CRM.
However, there are a couple of features, not yet present in CiviCRM, which would make it much more useful to fund raisers in India. I am sharing one of those requests here, for your feedback and suggestions. In particular I would very much like to know if this issue is also requested by users in other countries.
The Context
Competition with peers: Many non-profits motivate their fundraisers to meet their fundraising targets by linking their performance reviews or bonuses to the amount that they raise. Thus fundraising is both collaborative (where the team must meet an overall target) and competitive (where each team member works to meet her/his own individual deliverable). In such a situation, fundraisers are very protective about their own leads and may not wish to share them with peers early in the fundraising process. They do not mind if their manager has access to these contacts, as long as there is no threat of a peer 'poaching' a lead.
Sense of control over one's own data: Non-profits constantly add new contacts to their database, segregated into restricted and non-restricted lists. We implement ACLs for them as and when requested. However, they would rather be able to set the level of access by themselves while adding their contact or creating their group.
The Question
Both the situations described above are recurring in nature, across organizations. Is there a way that the end user (typically a non-techie) could decide whether they wish to keep a particular contact or group private, share it with a specific user group (say all fundraisers in their office), or make it public for anyone who has access to the organization's database?
Filed under
Comments
I recommend you ser up Access Control Lists so that each fundraiser has their own group of contacts that they can view and edit but not other fundraisers. The supervisor should be able to view and edit all fundraisers lists, and also unassigned contacts. fundraisers can't view unassigned contacts until supervisor assigns contact to them by, for example, putting in a group with a fundraiser's name that is used to define the ACL. Note that you need to restrict the permission to edit which group a contact is assigned to so that only a supervisor can do that. There are many options, one is to create smart groups based on value of a Select field, and use a different ACL to make that field editable only by a supervisor group.
HTH
Thank you for your suggestions Joe!
We have created group-based ACLs for these non-profits in a way very similar to what you suggest. However, the users want to be able to choose permission levels of access of a contact or group, all by themselves. It seems they are looking for more control, flexibility and ease of use where the sharing of information is concerned.
The ACL screen is complex for them since they are brilliant in their own fields but are definitely non-techies. Therefore, at the moment they have to route ACL requests to us, and even with quick turnaround time they look upon it as an additional step of coordination with the service provider. Have you come across a similar sentiment from end users?
Typing on a tiny smartphone isn't a great way to write posts. Sorry.
I would name the groups in a way that includes the Fundraiser's name who is responsible for those contacts.
This can all be done manually through the browser but it will not be convenient to maintain as fundraisers come and go. A small extension could automate things nicely.
One approach would be to have a static group of Fundraisers. On the post hook for adding and removing contacts from the fundraisers' group one could manage the creation and removal of groups and ACLs for the new or removed fundraiser. This would allow a supervisor to just look after assigning contacts to be fundraisers, and other contacts to be the prospects in the fundraisers' lists.
Anyway, just a few ideas to play with. There are lots of alternatives, and with more thought a simpler and more usable design might be possible.
Thank you again. :)
Do you have an example of this approach that my team could look at? It would be interesting if it gives the end user more flexibility in selecting which colleagues should or should not see any contact/list that they add.
We have done some work around using Relationships to drive the ACL - Eileen may get around to providing a bit more info if we haven't already posted about this approach.
eg if I add Contact B with Relationship X, then that adds them to the contacts I can see, and other users, who are restricted to seeing only contacts with whom they have Relationship X, wont see them.
But if I add or change Contact B to having Relationship Y, then they go in to a Group that all of the Users have ACL access to.
If that sounds like an option then one way might be to use a Drupal Webform that allows the people adding the contacts to specify what type of Relationship to have between them and the contact.
I may not have thought through some gotchas, but will leave that for you to do.
Thank you for sharing this approach. I haven't tried a relationship-based ACL yet, but I will to understand what the user experience would be for the non-techie end user.
At the risk of reducing too much, one way to summarize this might be to say "the mental model for ACLs in Civi is too complex -- we need a simpler one."
To demonstrate this, look at how we determine whether contact X has permission to view contact Y. You basically do five joins: from X to his groups; from X's groups to the roles of the groups; from the roles of the groups to the ACLs; from the ACLs to the targetted contact groups; from those contact groups to contact Y. To configure each of these joins, you're facing 2-5 pageviews. In sum, if you want to set the permissions between contact X and Y, the pageflow will include ~20 page-views.
Of course, this complexity must exist for a reason -- it made sense to someone, and it gives some power/flexibility that wouldn't exist in a simpler system.
In any event, a few approaches to simplifying the UX:
Thank you for spelling out these options along with their pros and cons so clearly, Tim.
When you visualize the final user experience, which of these would be simplest for non-techie end users to quickly share specific contacts/groups with colleagues and with zero dependence on anyone else (including their manager)? Also, could it be made equally simple for fundraisers using CiviCRM in multi-location offices or non-profits with local chapters?
We recently implemented ACLs for two non-profits based on name of fundraiser, location and seniority (Fundraiser - Fundraising Head - Director Fundraising), and ended up with a large number of groups in the Add Contacts screen and the select recipients section of CiviMail.