Start tracking your progress
Trailhead Home
Trailhead Home

Focus on Salesforce Key Platform Best Practices

Learning Objectives

After completing this unit, you’ll be able to:

  • Recall key best practices for implementing the Salesforce platform.
  • Consider general security features in Salesforce.

As we mentioned in a previous unit, Salesforce is a powerful and complex tool, so before we jump into the specifics of setting up NPSP, we want to point you to some key best practices in implementing the platform that powers NPSP. This module is a high-level overview of some of the things you should think about as an admin. Again, when you’re ready to dig deeper, check out the resources included as part of this unit.



If you plan on becoming a super user of Salesforce, you should plan to take the Admin Beginner trail at some point. It goes into more details on many of these topics.

Protect Your Data with a Security Strategy

As you get ready to move into your new CRM home, it’s time to think about access and security. Where do you install locks or child-safety devices? Who gets keys and passcodes?

Your organization has an awesome responsibility to your constituents, who have entrusted you with their donations, and by extension, their personal data. You’re expected to protect their data from misuse and inappropriate exposure, while also giving your staff reasonably convenient access to data they need to do their jobs.

Protecting your data is a joint responsibility between you and Salesforce. Many layers of Salesforce security work together to keep your data safe. Your data is protected from unauthorized access from outside your organization, and you also want to safeguard it from inappropriate usage by your own users. Salesforce takes care of keeping your data stored where others can’t get at it, and we protect it as it moves over the network. You keep track of your users, making sure the right users can work with the right data. Together we train your users to keep their data safe.

Salesforce gives you a flexible set of tools that help you balance security and convenience. Once you’ve designed and implemented your data model, give some thought to the kinds of things your users are doing and the data they need to do it.

Levels of Data Access

You can control which users have access to which data in your whole org, a specific object, a specific field, or an individual record. 


For your whole org, you can maintain a list of authorized users, set password policies, and limit logins to certain hours and locations.


Access to object level data is the simplest thing to control. By setting permissions on a particular type of object, you can prevent a group of users from creating, viewing, editing, or deleting any records of that object. 

You can set object permissions with profiles or permission sets. A user can have one profile and many permission sets. 

  • A user’s profile determines the objects they can access and the things they can do with any object record (such as create, read, edit, or delete).
  • Permission sets grant additional permissions and access settings to a user.


You can restrict access to certain fields, even if a user has access to the object. For example, you can make the salary field in a position object invisible to interviewers but visible to hiring managers and recruiters.


You can allow particular users to view an object, but then restrict the individual object records they're allowed to see. For example, an interviewer can see and edit her own reviews, but not the reviews of other interviewers. You can manage record-level access in these four ways.

  • Organization-wide defaults specify the default level of access users have to each others’ records. You use org-wide sharing settings to lock down your data to the most restrictive level, and then use the other record-level security and sharing tools to selectively give access to other users.
  • Role hierarchies give access for users higher in the hierarchy to all records owned by users below them in the hierarchy. Role hierarchies don’t have to match your organization chart exactly. Instead, each role in the hierarchy should represent a level of data access that a user or group of users needs.
  • Sharing rules are automatic exceptions to organization-wide defaults for particular groups of users, so they can get to records they don’t own or can’t normally see. Sharing rules, like role hierarchies, are only used to give additional users access to records. They can’t be stricter than your organization-wide default settings.
  • Manual sharing allows owners of particular records to share them with other users. Although manual sharing isn’t automated like org-wide sharing settings, role hierarchies, or sharing rules, it can be useful in some situations, such as when a recruiter going on vacation needs to temporarily assign ownership of a job application to someone else. (Available in Classic only)

Just because Salesforce gives you all these powerful security options, it doesn't mean you should implement them all. It would kind of be like putting on ALL the sweaters you own when the weather calls for snow. Determining how best to control data access at your org takes a thoughtful balancing of  risk and usability. You want your security plan to be as simple as possible while mitigating the majority of risk. You want to choose the sweater that will keep you warm while still allowing you to win the snowball fight! 

User Profiles

In addition to the standard Salesforce user profiles, NPSP comes pre-configured with several custom profiles. You’ll want to review the object permissions that come with these profiles before you assign them to a user. You can also create custom profiles to meet the specific needs of your organization.

User Profile
Standard or Custom
Marketing User
System Administrator
Executive Management
Custom to NPSP
Fundraising and Development
Custom to NPSP
Office Staff
Custom to NPSP
Program Staff
Custom to NPSP
Custom to NPSP

Make a table of the various types of users in your organization. In the table, specify the level of access to data that each type of user for each object and for fields and records within the object. You can then refer to this table as you set up your security model.

With data security, we recommend keeping things as simple as possible — for your sake and the sake of the folks who might come after you. To dig deeper into the details of data security, check out the Data Security Trailhead module link in the Resources section below. 

Let Your Requirements Guide Your Customizations

You can customize and configure a lot in NPSP with basic point-and-click tools. Here are just a few of the common ways that nonprofits customize NPSP for their users:

  • Home: Create custom home pages for different departments in your organization. Your development team might have a different home page with different components than your program team. The home page helps your teams find the information they need quickly and drives adoption.
  • Fields: Add custom fields to standard objects, to track even more data. For example, add a custom field to keep track of contacts who are alumni of your programs. Or a custom field for donor or grant research.
  • Page layouts: Customize the page layout so that fields and sections are easy for your users to navigate and enter the most important data quickly.  Or include a new section for those custom fields you added.
  • List views: Create custom list views to help your users find, sort and work their records more effectively.
  • Search: Configure search results to make it easier for your users to find what they need quickly.

Automate Your Organizational Processes

One of the most powerful things that Salesforce and NPSP can do for your users is to help them work more efficiently by automating some of your organizational processes. There are four key point-and-click tools in Salesforce that can help you automate both simple and complex processes. These tools help you choose selection criteria and automatically update or create new records, emails, and tasks, or submit approval requests all in a few steps. 

Approval processes automatically route a record to the right Salesforce users, who then approve, reject, or reassign it. Based on how users respond to the record at different steps throughout and at the end of the process, Salesforce performs automated actions. 

Process builder is a point and click designer that lets you automate multiple rules (sets of criteria and actions) in a single process. When a new or updated record meets your specified criteria, the process kicks off and performs the actions you configured. 

Workflow rules operate as individual if/then processes that can automate a subset of the actions available in Process Builder. 

Flows automate virtually any process. Use it to automate processes that you can’t automate with the other three tools, like wizards or background processes that use complex branching logic. 

Build, Test, and Train in a Sandbox

If you are going to customize your Salesforce org after your initial implementation, or if you want to test out an app from the AppExchange, we recommend setting up a staging environment where you can test changes without affecting your live (what we call your “production”) org or its users. A Salesforce sandbox is a copy of your production org. You can create multiple copies of your org in separate environments for different purposes such as testing and training, without compromising the data and applications in your production organization.

Every customer has, at a minimum, access to several developer sandboxes and a partial copy sandbox (the exact number and type of sandboxes are determined by your license type). 

Our NMH admin Gorav wants to set up a new developer sandbox for user training. Let’s follow along as he creates a new sandbox.

  1. From the Setup menu ( gear icon), click Setup.
  2. In the quick find box, enter “sandboxes.”
  3. Click Sandboxes. The sandboxes page shows you the number of available sandbox licenses and sandboxes you have already set up.
  4. Click New Sandbox.
  5. Enter “QA” as the Name and “for previewing and testing new releases” as the Description.
  6. Click Next under the type of sandbox you want to create. Gorav selects a developer sandbox.
  7. If you don’t see the type of sandbox you want, contact your Salesforce account executive to order more sandboxes.

If you use a sandbox to create and test configuration changes in your org, you can use change sets to send customizations from your sandbox to your production org. Change sets bring over modifications you make through the Setup menu into your production org.

Empower Users and Shepherd Adoption

As your move-in date gets closer, your focus will shift to ensuring a smooth transition for your staff. Like any move, it takes a while to unpack the boxes and get settled in. New surroundings will feel unfamiliar to your users and activities that used to be routine can feel initially frustrating.

Change can be hard and disruptive. We encourage you to plan for an adjustment to the newness and the uncertainty, and even some resistance. Take stock of the situation in advance:

  • You’ll likely know where you’ll encounter pockets of resistance to change.
  • By now, you’ve worked enough with your implementation team to know who your power users are. Offer training for these folks on how to coach other users, and establish a “buddy” system if that fits your organizational culture.
  • You know who on your team is skilled at providing emotional support. Involve these folks, lean on them, and encourage anyone having a hard time to lean on them, as well.

You can count on some emotional responses to all the changes, but you can also count on your users being resilient and resourceful. They do work for a nonprofit, after all! After everyone settles in, we’re confident that it’s possible for your organization to have happy, empowered Salesforce users who’ve become even more excited about carrying out your mission.

Gorav, the awesome admin at No More Homelessness, reviews the implementation checklist with the team.

Your implementation checklist is your guide to giving your new residents a welcoming, homey feel, right from the moment they approach the front door for the first time. Take the lead from Gorav, who created this checklist to keep the No More Homelessness implementation on track:

Pre Roll-Out Post Roll-Out
Create a Communications Plan in coordination with key stakeholders. Engage Executive Sponsor to announce launch date and be sure to lead with the value the new technology will bring to users.
Monitor logins and usage
Sign up power users as volunteers for testing. Manage testing process with small group weeks before larger roll-out.
Track and respond to bugs / users questions.
Adjust setup and customizations based on feedback from testing.
Encourage Executives to celebrate adoption success and recognize key champions. Consider small perks for super adopters - free lunch, coffee gift card, etc.
Create a Training Plan for users including: custom Trailmixes, cheat sheets, short screen recordings, PDF’s. Ask users how they best like to learn.
Survey (formally or informally) users at 3 months and 6 months post implementation.
Set up a sandbox and conduct training sessions for a small group of power users / champions.
Offer refresher training.
Finalize launch date.

Create and document feedback loops. Set up system for logging bugs or user questions (could be as simple as a spreadsheet or form, or use Chatter or the Case object in Salesforce)

Schedule training and coaching for end users on custom features.

Now that you have a better understanding of some of the things an admin needs to think about when implementing Salesforce, let's log in (about time, right?) to an NPSP org and navigate to Setup and NPSP Settings.