Implementing Salesforce for Volunteer Users

Volunteers are often the heart and soul of small nonprofits – they put in their blood, sweat, and tears, they don’t get paid, and they are happy to be contributing their time towards something they believe in! When those small nonprofits are using Salesforce, very often so are their volunteers. When your user base includes lots of volunteers, there are a number of things to consider – and a number of things you might do a little differently than if your user base is paid staff. What’s the difference?


  • Don’t have as much time for training
  • Don’t do the work as frequently or regularly as paid staff
  • Have varying experience with and background in technology and databases
  • Are often working at off-hours, when either you as the Salesforce implementer/administrator/trainer are not working, and/or the organization’s paid staff are not working

Some considerations for Salesforce implementations and support for volunteers:

Be realistic about what’s feasible – and what’s not

A few years ago, I implemented Salesforce pro bono for a small nonprofit with a single paid staff person and a fleet of volunteers. This was an organization whose work was based around community organizing, and as such, the staff person and volunteers all conducted many 1:1 relational meetings. Salesforce Activities would be perfect for documenting these, I thought! When I presented them to the Executive Director, however, she rejected the idea. “It’s cool, but we won’t keep up with it. Maybe sometime down the line.” Lesson learned, and I’m so glad this ED was far more realistic than I in that moment! One mistake to avoid here is not to implement something that the organization’s users do not have real time to learn or the ability to maintain, despite the temptation of Salesforce providing countless out-of-the-box solutions for a range of business needs. For many small nonprofits with volunteer users, the initial Salesforce buildout itself can be simple and straightforward, while more time may be spent on training and documentation than in other implementations.

Security and permissions – more important than ever!

Many people believe that smaller organizations are less in need of Salesforce’s built in security and permission features. And sometimes, that is true! However, when your users are all volunteers, it is essential to make the system as foolproof as possible. Because of time constraints and scheduling difficulty, volunteers generally receive minimal live training, and may be rotating in and out fairly frequently. Do them a favor and make it impossible for them to mess anything up! Their Salesforce tasks should be outlined clearly and they should be assigned profiles that only allow them to see/modify the data they need to see/modify and do the tasks they need to do. Implement validation rules as needed. For example, volunteers doing data entry of Contacts from an event do not need to be able to edit Opportunities (in some cases they don’t even need to see Opportunities). If your Contact object has hundreds of custom fields, perhaps create a profile for those volunteers that only has the key fields they need to work with. Doing this work ahead of time can save your volunteers and paid staff time and headaches, not to mention saving the organization money that they might have paid you or another consultant to help clean up bad data or recover missing data.

Prevent duplicates

From day 1, set up Salesforce’s Duplicate Management feature (released Spring ’15). It is fairly simple and straightforward to set up, and your volunteers will thank you for helping them not reinvent the wheel or enter bad/repeat data in the system.

Foolproof documentation is key

Work with your main contact person to create guides, whether written out or in short videos, to document key business processes the volunteers will need to work through in Salesforce. Tools like Crowdguide and Screensteps can be particularly useful here, as they provide embedded guides of different styles to walk your users through a process. If there’s no budget for a documentation tool, use Salesforce Solutions or just a Word doc – whatever can be shared and updated easily!

Train your paid staff person (or main contact person, if they are a volunteer) to make basic administrative changes

Your staff member does not need to be a fancy dancy 5x certified Salesforce professional, but they should know enough of the basics and be familiar enough with the Setup Menu that they can understand how objects relate to one another, where custom fields can be edited and created, how to modify page layouts, and how to create and modify reports. If they are particularly savvy, you can introduce validation and workflow as well. Given the size of the organization and the fact that they have so many volunteers, I’m going to go out on a limb here and guess that their budget for ongoing Salesforce support is pretty minimal. Make it as easy as possible for them to make changes on their own before they have to reach out to you.

Set up some basic data quality reports

Now that you’ve set up your security and permissions, documentation, trainings, and duplicate prevention, set up some reports to help the organization monitor the quality of the data. Have the report/s emailed on a weekly or monthly basis to your main contact person, paid staff person, or the person you trained to do basic administration. If after reviewing these reports, that person is seeing major data quality issues, revisit validation rules, training, documentation, and permissions and adjust as needed.

Volunteers rule! Give them the easiest, most foolproof system and keep them and the organization’s time and money focused on their mission, not on cleaning up data. Have more tips for implementing Salesforce for volunteer users? Please leave them in the comments!

Making the Case for Documentation

It seems appropriate that my first post on this new blog would be about documentation. How meta! When I say documentation here, I’m focusing on documenting what’s happening in the setup menu for the benefit of anyone searching or trying to make sense of administrative settings, though much of this applies to different kinds of documentation.

I have thought about this topic so many times since starting at my most recent job as a Salesforce Administrator at Year Up, a large nonprofit organization with 600 (and counting) active Salesforce users and a dedicated team of 7 working on current and future Salesforce functionality. Why is documentation so important in a Salesforce setup environment?

Perhaps the most obvious: no one knows exactly what you’re doing or why, except you

None of us works in a bubble, even when we are a rockstar solo admin. If we rock enough, we’ll head off to a bigger, brighter organization after some time. And someone’s going to have to know why you did what you did.

Sometimes even you don’t know why you did something

Right in the moment you think, this makes total sense! And I need to do this task and move on so I can get on with my busy day. And some time later, you stumble on that same formula field and cannot remember why you put it there. This morning my co-admin asked me why I created a particular Public Group six months ago. Now, I remembered creating the group, and I remembered that there was an actual reason for it. I went digging through the helpdesk ticket archive, sharing rules, report folders. Nothing. Oops. Could have prevented this one, easily, with some simple documentation.

Nonprofit Salesforce setup can be complex

When you’re building custom fields, workflows, validation rules, and processes that are specific to your organization’s mission, program, and business processes, things that start off seeming fairly obvious can get obscure pretty quickly once you’ve gathered your requirements from your staff and started building. Furthermore, if you’re paying a developer write a trigger for you, or you’re an #AwesomeDeveloper and are writing it yourself like a rockstar, I can tell you for certain that no one knows what that thing does besides you. And I’m sure it does a lot of cool stuff, because it’s custom coded.

Data is flying in from everywhere!

Where did this data come from? Was a big mantra at my last system administrator job. We had data generating and updating from webforms, a gift processing vendor, custom apex code, and the Rollup Helper application, not to mention from our own users. If you have a field only being updated by one of those groups, put it in the field description! We incorporated this as standard procedure for adding new rollups. The description would read something like:

Populated by rollup helper {insert link to rollup details here}.

Simple as that. That way, when you, a fellow administrator, your successor, or anyone else with admin access goes into the setup menu to understand what the field means, they can find out easily and quickly.

So why is it worth our time, and therefore our money, to do this?

The short answer to this one is that a little bit of time invested at the beginning can save hours of time later on. Not prioritizing documentation is taking a short-sighted view of Salesforce implementation and maintenance. Helping yourself – or your coworker or successor – remember or understand what you did can prevent the frustration and time of digging through the setup menu for an afternoon, running 5 reports, calling vendor helpdesks, deleting something important (because no one understands its importance), or reinventing the wheel by putting something in the system that might already be there with a different name but no description.

But I’m using a consultant, and they’re doing all of our buildout for us!

The case for documentation might be even stronger if you’re working with an implementation partner. They’re building stuff for you – make sure they give you some documentation for what they did, and why! It will likely save you hours of time and headaches later. Remember, Salesforce implementation is an ongoing process, not a one-shot deal. The more your consultant documents, the less likely it is that you’ll have to call them again and again to ask questions or modify something after the solution has been implemented.

Where should I put it?

Anywhere where it will be easy to find, search, and update. Use description fields everywhere you go and make it a standard part of adding any new field, workflow, validation rule, etc. If we’re talking lots of complexity, like a custom object, use Salesforce Solutions! Start a wiki! Use your organization’s intranet, if you like it and it meets the criteria above (easy to find, search, and update). Start a Word doc or a google doc!

Last tip: documenting does not have to be wordy or complex. Outline the basics of whatever you built. Your reader will thank you for your brevity – because it will make their job easier. And with that, happy documenting!