Setting up Volunteer Management is mostly an exercise in connecting four pieces: the volunteer-facing Experience Cloud site, the Volunteer Jobs and Shifts that publish to it, the hours-tracking flow that volunteers and coordinators use to log time, and the reporting that ties it all back to the constituent record. The Nonprofit Cloud install handles most of the underlying metadata, but each of those four pieces needs configuration work specific to the way your nonprofit operates day to day.
- Install Nonprofit Cloud and provision the Volunteer Management module
From Setup, install Nonprofit Cloud if it is not already in the org. Confirm the Volunteer Management feature is enabled in the Nonprofit Cloud settings page. Run the Volunteer Management onboarding wizard, which provisions the necessary objects, record types, permission sets, and the volunteer Experience Cloud template. Older orgs migrating from V4S should do this in a sandbox first and use the Salesforce-supplied migration playbook to map V4S records into the new Nonprofit Cloud objects. The migration is not a single click; it is a planned cutover with data validation steps at the start and end.
- Create Volunteer Jobs and publish them to the volunteer site
For each type of volunteer work the org needs, create a Volunteer Job record with a clear description, the skills required, the typical commitment, and the location or program it belongs to. Mark the job as Public to publish it to the Experience Cloud volunteer site. Add Volunteer Shifts under the job for the actual schedule. Recurring shifts are modeled as a series record with individual instances. Test the public listing by previewing the Experience Cloud site as a guest user, since published jobs that fail to appear are usually a sharing or guest-user-license issue rather than a configuration mistake.
- Configure the hours-capture path that fits your operation
Pick the hours-capture method that matches how volunteers actually work in the field. For office-based volunteers, the volunteer portal self-log path is usually enough. For event-based volunteers, set up the kiosk sign-in or the Volunteer Mobile app to capture hours at the event. For program-based volunteers managed by a coordinator, configure the bulk roster check-off page. Each path writes a Volunteer Hours record. Pick one as the primary and treat the others as backups so reporting stays clean and you do not end up with double-counted hours across the year.
- Build the dashboards that turn hours into impact
Reporting is where Volunteer Management proves its value. Build at least three dashboards: a coordinator dashboard (today shifts, no-show rate, hours logged this week), a program dashboard (hours per program, top volunteers per program, retention rate), and a board dashboard (total volunteers this year, total hours this year, hours per program). Each dashboard pulls from Volunteer Hours rolled up through standard report types or a custom report type. Add filters for time period and program so the same dashboards work for monthly reviews and the annual report.
- Volunteers for Salesforce (V4S) and Nonprofit Cloud Volunteer Management use different object API names. Reports built on V4S objects do not work after migration; rewrite them against the new schema.
- Background check workflow varies by jurisdiction. Do not hardcode rules in a Flow; surface them as record types or custom metadata so program coordinators can adjust without code.
- Public-facing job listings need a configured guest user license on the Experience Cloud site. Missing sharing rules for guest users is the most common reason jobs fail to appear publicly.
- Self-logged hours need a confirmation step. Without it, no-shows and exaggerated hours pollute the rollup totals that drive the annual board report and grant impact statements.
- Skill matching only works if both Contacts and Jobs use the same skill picklist. Free-text skill tags break the matching logic and force coordinators back to manual scheduling.