CiviVolunteer 1.3 is out with bug fixes and new features

Published
2014-02-11 11:34
Written by
universalhandle - member of the CiviCRM community - view blog guidelines

This weekend I pushed out version 1.3 of CiviVolunteer. It contains a handful of bugfixes (check out the commit history for more on that) and a new feature that is the subject of this post.

CiviVolunteer 1.3 introduces the concept of "project beneficiaries." This release allows admins to specify a contact which benefits from or is the target of a volunteer project. For organizations which broker volunteers as a service to other organizations, this feature facilitates recording and reporting the number of volunteer hours provided to each partner org. Organizations with a chapter structure will find the project beneficiary useful as well, as service or volunteer hours often have implications on funding from the umbrella group.

I've prepared a quick screencast to demonstrate how CiviVolunteer 1.3 approaches beneficiaries. This is our first pass at supporting project beneficiaries, so we'd love to hear your reactions to what we've got so far and your ideas as to where we should go next. The comment section below is probably a good place to start the conversation. Thanks!

Filed under

Comments

Thanks for all your work ont this so far, it is a great extension.   I have some questions about how to best use the beneficiary field:

A common scenario that requires many volunteers is when a person has died, and the religious congregation needs a number of volunteers across many days to help with things for the mourner(s).   I am thinking the "beneficiary" could either be the newly deceased contact, or the mourner (such as the widower).   That way the coordinator can easily see all the volunteers helping a particular mourner.   Is this a correct use of beneficiary?    (Also, it may be nice to allow multiple beneficiaries. Such as the beneficiaries may be the adult son and adult daughter of a person who recently died.  Or we may want to track the "chapter committee" who is getting credit for the volunteers, in addition to the mourners. ) 

Also, in many situations there may also be a CiviCase related to the same situation. The case is typically used within the office to assign a clergy to officiate at the funeral, track phone calls with the mourners to plan the funeral details, etc.   Seems like there is some overlap between CiviVolunteer "shifts" and CiviCase "Timelines/Activity Sets" because both represent activities that need to happen. 

Another common scenario which also requires a lot of volunteers and also has a case, is when a member of the congregation is dealing with a serious long-term illness.  In this situation, I am thinking the beneficiary would be the sick person.

Thoughts?

 

Was also thinking it would be helpful if CiviVolunteer actvity records could be automatically associated with a CiviCase. 

Hi, Sarah,

Currently the beneficiary field supports only one contact. Changing this would involve mostly UI tweaks and possibly also some form handling updates, but the underlying schema would not need to change to support this because of the way CiviVolunteer is architected.

In the example you give, I think you could go one of two ways.

If assigning the target contact on activities isn't particularly important to you, then you don't need to use the target beneficiary at all. Each project would correspond one-to-one with a funeral, so it would be easy to see everyone who volunteered to help with John Doe's funeral arrangements.

I feel that assigning multiple targets in the case of a funeral could get a little arbitrary/confusing. Where do you stop? Just the spouse? Children? First as well as second husband? It makes more sense to me to use the beneficiary field to specify the "chapter committee" getting the credit for the volunteer service.

In this case, the language gets a bit confusing. Arguably, the deceased and his or her family are the beneficiaries of the volunteer effort, not the chapter committee. In other cases, e.g., if my organization brokers volunteers for local humane societies, a chapter or organization actually is the benefitting from the service. I struggled a bit with the best language for this (the Civi "target contact" parlance seemed too user-unfriendly), and I'm certainly open to input on it.

I can see some potential overlap with CiviCase (especially with the long-term illness scenario you described), but I think these tools naturally lend themselves to different workflows, so I'm not yet concerned about duplication of effort. I would be interested to hear your thoughts on potential integration points between the two. It sounds like you have a lot more experience using CiviCase than I do.

Cheers,
-Frank

Anonymous (not verified)
2014-02-21 - 07:50

Thanks for creating civiVolunteer! I've downloaded and installed it but am getting the following error when I try configuring it for an event. Can you explain what the error means? I've configured dozens of events before so know what I'm doing. The civiCRM installation though, is a new one.

"Sorry but we are not able to provide this at the moment.

Not enough data to create volunteer project object."
 
Thanks!
Richard Simon
Bermuda