Skip to end of metadata
Go to start of metadata

The following are initial specifications for a Volunteer management module for major events that was to be developed in Drupal for CiviCRM. Funding was not sufficient to proceed with implementation, but various organizations and individuals over the years have continued to express support and interest.

It is intended to provide Volunteer Management functionality for events specified in CiviEvent Phase I or Phase II. Additional similar functionality is detailed to support the management of volunteers for committees. The modules support a workflow where Volunteer Coordinators specify roles that need to be filled, volunteers indicate their interests and availability, and coordinators assign volunteers.

Pride Toronto ( manages Toronto's Pride Week events. Over a million people participate, and over a thousand volunteers help in over 50 events at a large number of venues. They have decided to replace a legacy desktop volunteer scheduling and management system with a new one based on Drupal / CiviCRM. There is a need for volunteer coordination to ensure that there are enough adequately trained volunteers available to fill various roles throughout the three day Pride Weekend at the end of Pride Week. It is also necessary to track the number of hours worked by volunteers who have positions on various planning committees throughout the year, and / or who volunteer during the events on the main three day weekend of Pride Week.

More requirements have been added based on work with several different volunteer organizations in Frederick County, Maryland.  These include organizations such as The Literacy Council, Volunteer Frederick, The Frederick County Historical Society and The Schifferstadt Museum.

Here are some of the core needs:  


Just a little bit of information for the organization

  1. Types of Services Provided such as
    1. Workplace Literacy
    2. ESL
    3. GED
    4. Math
    5. Prison Literacy
  2. Membership ID if they belong to a larger group

Type of Volunteers

There are several different types of organizations and they have different types of needs

  1. Event volunteers - Usually associated with an event and can have several different types of volunteers for a single event. For example, ticket takers, concession stand, crowd control, speakers, etc.  A lot of times anyone can sign up but sometimes they need to be cleared first or there's an approval process or only certain types of volunteers are allowed to sign up. Also need the capability to assign time slots to volunteers for a long event. For example, need ticket takers for 10 to noon, noon to 2 for a 10 AM to 2 PM event.
  2. Trained volunteers - Sometimes associated with events but usually associated in a one-to-one relationship. For example, tutors or people to help with the elderly or other items.
  3. Volunteers with specific equipment - sometimes need volunteers with specialized equipment or capabilities. Good examples are for Civil War re-enactors where they need people with canons, etc.


There should be several types of users - see volunteer, staff, etc.  However, there are non-profits that need to schedule with people.  Literacy councils are great examples, some of the one-on-one help organizations such as domestic violence groups need to be able to schedule time while some organizations have special events - such as ghost tours.

  1. Agree to terms and conditions IF they're looking for assistance OR if they're providing assistance
  2. Be able to sign in as a supporter / donor / board member / staff / event attendee
    1. Supporter and donor would not need any approval process
    2. Board members, staff and people requesting assistance would need to be approved by a current staff member
  3. Search for available times for initial interviews BEFORE they've been approved for assistance
  4. Search and sign up for available volunteers at locations and times AFTER they've been approved for assistance
  5. Request assistance at a specific location and time AFTER they've been approved for assistance
  6. Some basic demographic information - age / sex / language / education level / occupation
    1. Age, sex, education level, language and occupation required for people requesting assistance
    2. Native English speaker or ESL
    3. Not required for donors, supporters, event attendees and board members.
  7. Some of the basic demographic information needs to have security around them. For example, cleared to work with children or other sensitive information
  8. User level - such as Beginner, Advanced or New / Graduate
  9. Date Certified or Approved
  10. Date Last Seen
  11. Outcome - such as Employability Skills, Wellness and Healthy Lifestyle
  12. Outcome Attained Date
  13. Some type of status - such as Active / Inactive / Pending / Discontinued
  14. Referral Source - Newspaper, Ad, etc
  15. Ability to be able to sign up to be waitlisted
  16. Ability to sign up for newsletter


Some basic types of events and they're mostly based on a number of people that can attend.  For example, the literacy council has a set number of people, some of the private tours of the museum of a limited number of attendees.  They just need to be able to report based on the number of people.:

  1. User requested
  2. One-on-one
  3. Small groups
  4. Large groups


Should be able to perform the following functions quickly and easily:

  1. agree to terms and conditions
  2. search, view, specify preference or sign up on available information about the following aspects:
    1. Roles -- such as Staff, Board Member, Volunteer, etc?
    2. Type or abilities - such as speaker, office staffing, publicity.  With multiple selections possible. Might want to switch the names and make this field Roles and make the Roles field User Type.
    3. locations
    4. times (date and start and end time)
    5. Select a user that has asked for assistance / times
  3. confirm or decline assigned shifts (defined by a role, location, and time) or assigned positions (defined by a role and start and end date)
  4. make changes to preferences
  5. revoke confirmation of shifts / positions
  6. indicate they should not be disturbed
  7. provide feedback through emails
  8. Someway to check in people - via iPhone or some other method. Want to track who's coming in the door for events.
  9. Notification through SMS or other quick type of communication
  10. attach pdf or other documents (eg signed releases)
  11. Volunteers should be able to pick shifts / events on their own
  12. Hours and type of work done - for example, preparation hours, teaching hours, travel hours, tour hours both scheduled and reported
  13. Some kind of status - Active / Inactive / In Training / Booted
  14. Ability to waitlist on events, classes, one--on-one.  For example, have backup for a ghost tour.
  15. Either ability to import information or enter in a base-line number of hours

Note: users need to be able to offer to volunteer in as general or specific a manner as they want. All information about the role, location, and times needs to be specified when assigning a shift, and for the role and dates for a position. Users should be able to specify multiple times throughout an event (eg Fri 6-10pm, Sat 10am - 2pm, 6pm - 8:30pm, Sun 9am - 11am) using a convenient AJAX interface. They need to be able to see how many people are required for each role during different periods if they want (Eg 6 people for roving security in the northern part of the parade route Sun 8 - noon), and to offer to help for shifts or positions that have already been filled (they then get put on a waiting list).

Volunteer Coordinator

Should be able to perform the following functions quickly and easily:

  1. create, review, update and delete the following
    1. volunteer roles - such as staff / volunteer / leader
    2. locations
    3. shifts (role + location + start time / duration) or positions (role + start date + end date)
      1. may be assigned to a volunteer or unassigned
    4. this includes the ability to
      1. quickly edit a group to specify new information common to all (likely by selecting all of the records in a group and then entering information to be applied to all)
      2. specify the number of shifts with a common role + location + start / duration
      3. specify the number of positions with a common role + start date / end date
  2. assign volunteers to shifts or positions by:
    1. dragging and dropping from available volunteers (filtered as desired, eg by location or role)
    2. approving or refusing shift / position assignment requests
    3. overriding shift / position assignment requests
  3. revoke volunteer assignments
  4. review:
    1. a volunteer's assignment interactions
      1. current
      2. history of changes for this year
      3. history for previous years, including did not show-up info and notes about suitability as a volunteer
  5. enter whether a volunteer shift was actually completed
    1. allow an override to indicate a shift was not actually completed
    2. changes to shifts would be used to track volunteers staying late/leaving early
  6. Enter in a cost per hour for each volunteer with a default value


In addition to the currently existing CiviCRM reports that can produce mailing labels and allow customized emails to be sent, some additional special reports will be developed to fulfill Pride Toronto's needs: 

  1. sign-in sheets
  2. assignment charts:
    1. by role names
    2. by volunteer name
    3. by location
    4. by matches - for example a volunteer has selected a time and date and the following people signed up for the event
    5. by no matches - for example a user has requested a time and date and no one has volunteered or vice versa
  3. shifts
    1. longer than 8 hours
    2. by committee
    3. no show
    4. attendance
    5. missing time entry - only for volunteers that signed up for an event but no time entered
  4. Demographics
    1. Counts and lists by event, type of event, type of attendee etc by some user defined time period
    2. Counts and lists for each role and type by some user defined period
    3. Counts and lists for sex, age and other types of demographic information
  5. Volunteer Reports
    1. by number of years
    2. by number of hours per time period
  6. Event List in alphabetical order
    1. By Volunteer / Attendee with contact information
    2. By Attendee / Volunteer with contact information
    3. Counts of Events by number of people
  7. Waitlisting
    1. Number of people waitlisted during a specific period
    2. Average time on the waitlist

Until CiviReport is available and is known to work on the client's ISP, it is anticipated that Crystal Reports will be used to define these reports and provide the ability for tech savvy users to produce ad hoc reports on the data with ease.

Design Overview


In order to reduce development time and the cost of maintenance, it is anticipated that the major event volunteer module will take advantage of several Drupal modules, likely including:

  • actions
  • cck (content construction kit)
  • civicrm
  • civinode
  • views
  • workflow

Data Model


Data will be stored for the most part in tables in CiviCRM. 

Volunteer start and end times for an event do not necessarily coincide with event start and end times displayed to participants. So there is a need to define this information separately for events and event volunteers.

Changes along the following lines will be made to the CiviCRM MySQL database:

  1. Create new tables to store roles
  2. Create a new activity_type of EventShift analogous to Meeting and Phonecall
  3. Create a new activity_type of CommitteePosition analogous to EventShift
  4. Create records in activity table for every EventShift and CommitteePosition
  5. Create an EventShift table and enter a record for each EventShift activity record
  6. Create a CommitteePosition table and enter a record for each CommitteePosition activity record
  7. Create records in activity_history table documenting:
    1. preferences
    2. changes to preferences
    3. assignments
    4. confirmations
    5. revocations (either by volunteer or coordinator)

New tables

  1. civicrm_role // stores roles for volunteers either for events or for enduring things like a committee: could be split into two tables civicrm_event_role, civicrm_committee_role
    1. id, INT, primary key
    2. domain_id, INT, fk to civicrm_domain
    3. name, VARCHAR(64)
    4. event_id, INT, fk to civicrm_event, NOT required
    5. group_id, INT, fk to civicrm_group
    6. role_type, enum (EventVolunteer, CommitteeMember)
    7. Constraint: if role_type=EventVolunteer, then event_id is required else event_id must be null
  2. civicrm_event_shift // stores information about volunteer shifts of work at events
    1. id, INT, primary key
    2. domain_id, INT, fk to civicrm_domain
    3. event_id, INT, fk to civicrm_event, NOT required
    4. role_id, INT, fk to civicrm_role, NOT required
    5. start, datetime, NOT required
    6. duration_hours, INT unsigned, NOT required
    7. duration_minutes, INT unsigned, NOT required
    8. contact_id, INT, fk to civicrm_contact, NOT required
    9. description, text
    10. volunteer_status_id, implicit FK to civicrm_option_value where civicrm_option_group = volunteer_status
    11. completed, boolean, default=false
    12. Constraint: one of event_id or role_id is required
    13. Constraint: (contact_id and one or more of
      (role_id, (start and duration_hours and duration_minutes), a location record pointing to this record)) or all fields except contact_id
  3. civicrm_committee_position // stores information about volunteer positions on committees
    1. id, INT, primary key
    2. domain_id, INT, fk to civicrm_domain
    3. role_id, INT, fk to civicrm_role, NOT required
    4. start, datetime, NOT required // only date is used
    5. end, datetime, NOT required // only date is used, if start non-null, then end is null means open-ended offer or commitment
    6. contact_id, INT, fk to civicrm_contact, NOT required
    7. details, text
    8. volunteer_status_id, implicit FK to civicrm_option_value where civicrm_option_group = volunteer_status
    9. Constraint: if contact_id is null, then role_id and start and end are non-null else either role_id or start is required to be non-null

Status State Machine 

  1. Volunteer coordinator creates records in civicrm_event_shift and civicrm_committee_position with status=CoordinatorCreated, and values specified for all optional fields except that contact_id is allowed to be null. No emails generated.
  2. Volunteer offers result in records in civicrm_event_shift and civicrm_committee_position with a VolunteerOffered status, contact_id filled in, and one or more of the other optional fields filled in. When not specified, it is assumed a volunteer is interested in all values for a field. A Volunteer Offer Received email is sent to user confirming details of offer received.
    1. Volunteer coordinator may change the status of record from CoordinatorCreated, VolunteerOffered or CoordinatorDeclined to CoordinatorApproved, which results in an email to user requesting them to Accept or Decline. All fields need to be filled at this point. 
    2. Volunteer response to email (either in a webpage or email link click) changes status from CoordinatorApproved to VolunteerAccepted or VolunteerDeclined. Email is sent to user confirming change in status.
  4. Volunteer coordinator may change the status of record from VolunteerOffered to CoordinatorDeclined; the volunteer coordinator has the option to send an email to Volunteer at this point.
    1. Volunteer coordinator may change the status of a record from CoordinatorApproved, VolunteerAccepted, or VolunteerDeclined to CoordinatorDeleted, which results in a notification email being sent to volunteer (to tell them not to show up).
    2. Volunteer response to email (either in a webpage or email link click) changes status from CoordinatorDeleted to VolunteerDeleteAcknowledged (so organization knows that other methods of notifying volunteer of change like phoning are not required). Email is sent to user confirming change in status.

Volunteer coordinator may physically delete a record with Created status.

Volunteer or volunteer coordinator may change value of completed.


Feedback on these draft specs from the community would be appreciated.

  1. Nov 30, 2006

    Is the current thinking to do CiviVolunteer+ a drupal front end?

    If so, could we just ride off of CiviEvent? When the CiviCRM team implements CiviEvent in 1.7, they also stub in the datamodel for CiviVolunteer... CiviVolunteer will have VolunteerOpportunity + VolunteerParticipant analogous to Event and EventParticipant.

    The Drupal front end uses the CiviCRM to store the opportunity and participant information, the Drupal front end uses that data via API.

    Not sure how we can map VolunteerOpportunity to shifts... shifts is best a property of VolunteerOpportunity.  

  2. May 28, 2007

    Another function worth exploring would be the ability to assign volunteers to other group members.


    Group 1: Volunteers

    Group 2: Home Care Recipients

    For a non-profit that recruits volunteers, and provides aide to others it would be beneficial to not have to create an event for every single client that organization serves. One could create an event called "Home Care Service" and then assign individual members from Group 1 as the provider, and members from Group 2 as the recipients.

    I work for an elder care organization that is currently paying over $3000/yr for poorly designed commercial software. I'd love to replace it with Drupal/CiviCRM, and plan to soon but the biggest challenge will be allowing our Personal Care management staff to effectively manage the scheduling of our Personal Care Workers. This is the most difficult task we require, everything else is simple Contact Management & Reporting.



    1. May 29, 2007

      Nathan - Your use case raises the question of the level at which the "Role" and "Shift" objects should live. Rather than assuming that Roles and Shifts are always linked to Events, we could allow them to be linked to a variety of "target entities".

      This would allow a Volunteer / Shift to directly link a Volunteer to a contact who is a Home Care Recipient.

      In the data model (civicrm_shift) - event_id would be replaced by target_entity_table + target_entity_id. This is similar to how we currently handle Notes, Tags and other objects which might be "about" a number of different types of things.

      1. May 29, 2007


        Let me know what I can do to help. That sounds like the right idea. Some sort of "Service Units" would be nice as well to be able to track each time a client receives service from a particular program. Many of our funding sources require these types of reports monthly...

        Additionally, I'm going to explore the possibility of linking CiviCRM with a full blown HR program such as Timetrex which would allow a CiviCRM enabled site to pretty much manage an entire Non-Profit operation, minus accounting for which we seem to be married to MIP for the time being. 

        1. May 30, 2007

          You might want to contact Joe Murray who wrote this draft specification and see if there's a way you can collaborate / help move this forward.

  3. Aug 02, 2007

    I would be keen to hear how this project is getting on and possibly contributing in my own small way. This looks to be a really interesting development that could be used by many volunteer-focused organisations here in the UK.

    How can I get an update?

  4. Aug 06, 2007

    Also interested to hear what happened to this idea. I would also ask whether there is some overlap with what Rob thorpe (question)  did for the Canadian Greens in their CiviCanvasser module which I understood also had a lot of volunteer mgmt capability. My interest is on behalf of the NZ Green Party which has the potential to make good use of a clearer volunteer mgmt approach for our election campaigns.

  5. Aug 06, 2007

    There is also the tie in around the CommitteePositions with the questions I have asked in terms of how we map our organisation in to CiviCRM as  I feel that our Positions need to be set up as 'entities' rather than as 'attributes' as Positions exist independently of the people filling them - especially as we want to be able to track the history of who was in which roles, and show all roles even those that are vacant. (pete for the NZ Greens)

    1. Aug 06, 2007

      I'll ask Joe Murray to respond to these comments and the status. The last we heard, they decided to build a few inhouse modules to make sure it was on time etc. But would be great to get folks to step up and help build this functionality in CiviCRM (smile)

    2. Aug 07, 2007

      Client specs have drifted somewhat, and new people coming in want a number of organization specific things. Putting together the install has not been that urgent for clients.

      We've ended up developing this entirely in Drupal, with an intent to synch at some point into CiviCRM at a data level using CiviNode.

      It's vacation time right now. Should have a release by end of August if not sooner posted on

  6. Aug 08, 2010

    Just want to offer any time or help here - starting to do some volunteer scheduling for the Literacy Council - pro-bono - but if I can add to the requirements or make them better....

    1. Jun 03, 2011

      Matt or Joe -

      Have either of you made any progress on getting either a drupal or CiviCRM module? I would be interested in contributing to a Make it Happen on this issue. 

      1. Jun 03, 2011

        I actually found that CiviCRM meets all of the current requirements for the Literacy Council.  I'm now working with another organization, Cakes for Cause, and waiting to see if anything needs to be done for them.  It seems as if CiviEvent and the Activity modules addresses most of the requirements I've come across.

      2. Jun 06, 2011

        Hi Carmi,

        This project has been inactive for a few years. It would be much easier to do now as an extension of the Activity toolset.

  7. Aug 13, 2012

    I've added my comments - I feel as if it's just a random list of notes. Is there a template of sorts to create requirements? I know a lot of these items are already available in other aspects of CiviCRM. I'll follow up with Lobo to see if he's looking for other things.

  8. Aug 13, 2012

    Heh Matt,

    I think that if you know of a possible source of funding for an initiative in this area then it makes sense to work on these specs here. If not, then I'd suggest working on suggested improvements in other areas of CiviCRM via the Roadmap.

    1. Aug 13, 2012

      Joe - only working on it because Lobo asked me to - don't know what the plans are, just blindly following the leader. Happy to help where's its needed!

      1. Aug 13, 2012

        Cool. I might try to put some effort in too then, but I'm about to head on vacation for a few weeks.

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.