When BRDPro collected requirements for BEAM and compared them to the VS4 (nonprofit volunteer management package) functionality, it was evident that VS4 job scheduling is too complicated for the simple recurring schedules that BEAM had. BEAM Volunteer Manager had two main requirements:
- Web site Volunteer Sign Up process was managed on Google Forms. The current web form fed the information to Google forms and the process was manual from that point on. The new solution needed to eliminate this process and improve it.
- The simple functionality they currently used for volunteer check-in/check-out and hours calculation needed to be provided by the new system.
Volunteer Manager made the schedules for volunteers herself manually and she had did not have a requirement for this functionality to be provided on the new system. Her volunteers worked every day from 9:00 am-2:00 pm for example. Creating jobs and shifts on VS4 was going to be an unnecessary burden for her.
When BRDPro was looking for an appointment setting solution during Phase 1, Brad Struss of Bigger Boat Consulting shared their blog that described similar solutions on the Power of Us Hub. A post on this blog titled ”Salesforce Volunteer Client Sign-in” had a potential solution. This blog post was describing a flow for volunteer sign-in that created and updated the hours object records available on VS4.
The project team decided to use Web-to-Lead web form for Volunteer sign-up and to create a flow for check-in and check-out for volunteers. Shift scheduling functionality of VS4 was not used at all.
The project team wanted to provide volunteers a simple solution. BEAM volunteers were using a screen, where they entered a four-digit code to check-in and out.
When BRDPro integrated Salesforce with Timetap for appointment scheduling we used the mobile phone number as a unique identifier in the system, since many of BEAM’s clients did not have access to an e-mail account.
The project team decided to use the mobile phone number for volunteer contact records as well. In the end, everybody is used to give out their mobile phone number as a unique identifier at the pharmacy, apparel shop and various other points of sale so that they gain access to each merchant’s loyalty benefits.
This is how the flow looked on Salesforce:
And this is how the flow worked:
- Check-in/out Screen: Enter mobile phone number and select check-in or check-out on the radio button.
- Get the contact record matching the mobile phone number. Pass first name, last name and record ID to variables and save for later use. Display error message if contact can not be found and abort.
- If check-in:
- Display all available locations on a radio button for selection. Save selected Location Name, ID and related job ID.
- Create a new hours object record using job ID saved and save the starting time stamp on the record. Mark status ”Confirmed”.
- If check-out:
- Get the Hours record created on the same day with status “Confirmed”, read the start timestamp on the record. Calculate the difference in time duration between now and the start timestamp in hours and save on the record. Update the status on the record to “Completed”. If such Hours record could not be found, show an error message and abort.
- Display message: Dear [First] [Last], Your [Location] [Check-in]/[Check-out] transaction was recorded successfully.
The initial versions of the flow used one single location and job. However, the Volunteer Manager needed to report back the hours in some of the locations to the relevant grants. Building nested decision points (nested if) to provide a few location choices would have not been a flexible solution. For the final version, a custom object called location was created. We needed to create one location record for each location, and a matching job record under a campaign structure fitting to BEAMs reporting needs. The flow called the location record set and showed all records on a radio button. As a result, when a new location is needed, all a user must do is to create a location record and a matching job record and save the required information correctly. The flow will automatically show the most up-to-date list of locations.
The final step was to give access to all the volunteers. Since most of the volunteers were not Salesforce users, a simple Visualforce page was created. The code on the page simply called the flow. A site was created with sufficient public access privileges that called this Visualforce page.
Please let us know if you have any questions. If there is interest, I may consider making a video on how this flow is built.
