Permissions, Sharing, and Roles, Oh My! Basic Salesforce Security for Nonprofit Admins

Security and data access in Salesforce are controlled via a powerful and difficult-to-master set of tools. Profiles, permission sets, roles, role hierarchy, sharing settings, and page layouts are all part of the toolbox. They offer different capabilities, but also overlap and interact in ways that can be difficult to wrap your head around.

As part of my work to simplify the permissions and security regime for a forty-seat nonprofit organization, I put together this basic primer on these tools, in hopes of offering ways into this intimidating and mystifying terrain. This guide is written with the small-to-medium sized nonprofit in mind.

Keep It Simple, Sys Admin

If you are planning a data security regime, keep your system as simple and as open as you can. When plotting data access, only restrict access to information that absolutely can’t be available to all staff.

The simplest data security regime is based on two types of users – one being system administrators, allowing access to all the administrative goodies like setting up new users and adding new fields, and the other providing access to all data but without administrative privileges.

You are unlikely to end up with this degree of simplicity. You will encounter solid organizational reasons for restricting access to some data, noting that “solid” in this case can mean either sound or immovable.  There can also be legal or compliance reasons for restricting data access, particularly if your organization provides health or social services.

But still, fight bravely for all the openness you can manage. The problem is that with so many layers and settings, understanding and maintaining a regime quickly becomes unwieldy. As even a moderately complex setup gets handed from consultant, to in-house admin, to in-house caretaker, and around again, the original justifications and thought-processes get lost. It can take many valuable hours to understand and update your settings.

So cajole and wheedle your colleagues when they insist that their data can’t be shared. Weaponize the phrase “data silo.” Ask hard questions, and demand solid answers. If there is data that is too sensitive to give all staff access to, ask whether you should be storing and collecting this data at all.

Record Sharing vs. Field and Object Access

The difference between record sharing and field and object access is fundamental in setting up and understanding your data security regime. This concept divides the security tools into two neat piles, greatly simplifying the overall task of understanding.

Field and object access determines what objects (opportunities, for instance, where donations, grants and proposals often reside) and fields (phone number, estimated net worth, etc.) a user can see, create, or edit. Field and object access are primarily controlled through profiles and permission sets.  

Record sharing allows you to control your users’ read and edit access to specific existing records on an object that they can otherwise access. Typically, this means restricting access to contacts and/or accounts based on their record type. For instance, your development department may insist that staff outside the department be prevented from seeing major donor contact records, whereas all staff can see volunteers’ records. Record sharing is controlled via sharing settings, roles, and hierarchy.

Sharing is caring

Salesforce is at its heart a sales tool, assuming an environment where sales staff are given a set of people or companies to sell to, information which is not shared with other salespeople, though it is available to sales managers and others higher up in the organization. (When I explain this to clients, I always have to stop myself from quoting Glengarry Glen Ross at this point, because no one typically understands me, and because of all the swear words. But it’s what I picture — a highly competitive, charged sales environment.)

As a result, the presumptive sharing model in Salesforce is based on the ownership of a given record, that owner’s role in the organization, and the hierarchy of those roles. This model probably doesn’t apply to most nonprofits, though it might apply, for instance, to direct service organizations managing client’s medical data. If your organization isn’t sharing records based on ownership and a tiered organizational chart, I have great news – you can completely ignore the role and role hierarchy sections of your toolbox.

In a nonprofit environment, it is more common that access to some contact and account types will be based on departments or teams within the organization. Donor records would be made available for editing to a public group called ‘Development Department,’ but might be read-only for other staff. Job applicants’ records would be available to human resources and upper management, but invisible to others. These requirements are implemented via sharing rules and public groups.

Restricting access to fields on those contacts, such as estimated net worth, would be handled via their profile or permissions, not via sharing. Access to related objects, like the opportunities records could be handled via permission sets, profile, or sharing settings. Note, though, that access to objects can be granted, intentionally or not, via the sharing rules on their related objects.

If you can have an entirely open organization, where all types of records are available to all staff (though perhaps not all objects or fields), you can ignore the sharing section of your toolbox entirely, opening access via profiles or permissions set to ‘Modify All’ or ‘View All.’

Field and object access: Profiles and Permission Sets

Profiles and permission sets are tools that control what fields and objects users have access to, and what sort of access they have: read only, edit, create, and/or delete.

Every user must have a profile. The profile controls access to almost every aspect of Salesforce – administrative privileges, the ability to create reports, access to chatter, password and login policies, and available apps, among many many others. The profile also includes settings for every standard and custom object and field in Salesforce. In addition to basic access, the settings offer a section of checkboxes for object record type. These settings control what record types a user with that profile can create, and the default record type for new records, but do not control the user’s ability to view or edit existing records with those types – for that, you must use sharing settings. The object settings also allow you to control what page layout is presented to users with that profile for each record type on that object.

Permission sets allow you to add *but never subtract* field and object permissions to those provided to a user via their profile. This includes the ability to create additional record types beyond those provided by the user’s profile. A user can have multiple permission sets assigned to them, but only one profile.

Salesforce offers a number of standard profiles. This, combined with the fact that admins are required to select a profile when setting up a user, tends to steer new admins towards profiles as the major tool for providing user permissions. It is common to see an organization with a dozen different profiles in use, one for each department or job title, regardless of whether there are functional differences in the access granted by these profiles. There is a downside to proliferating profiles — it is difficult to set profiles side by side to understand what if any differences exist.

It is easier to maintain a scheme that relies on a small number number of profiles, with permission sets used to add specific access for a group of users. Since permission sets can only add access, a well-set up permission set contains only the specific permissions that it adds to a foundation profile. For instance, a permission set for the development department will only contain settings allowing field access to sensitive development related fields, to the opportunity object, and other development-specific data. It is a simple matter to understand the difference between a basic profile, and that profile with a permission set added.

Some admins advocate using only one basic profile in addition to the administrator, and assembling all needed combinations of access by adding permission sets. This can add a lot clarity on the administrative side, but there are important trade-offs to understand when taking this approach:

• Profiles assign a default record type for new records created by a user, and permission sets cannot override this. If you have a single profile that assigns a default contact record type of ‘Standard Contact,’ you can give your development staff the ability to create record types of ‘Donor’ and ‘Prospect,’ but their new records will still default to ‘Standard,’ which they will need to remember to change. In most organizations, record types will be key drivers for reports, record sharing, and page layouts, so the single-profile model creates the risk of bad data disrupting key processes. You should consider a separate profile for positions that do a lot of data entry.  You can also address this challenge using validation rules or workflows to check or change record types, though that creates additional systems that need to be understood and maintained.
• Similarly, profiles allow the admin to assign page layouts based on record type, and this can’t be overridden by permission sets. In the interests of simplicity, I advocate for a single page layout for any given record type, not varying depending on the user, but there will be situations that favor a profile-based determination of page layout.
• When you create new objects and fields, Salesforce asks you to set access by profile. If your new object or field is to be accessed only by holders of certain permission sets, extra clicks are required to complete your set-up.

What’s Page Layout got to do with it?

Page layouts are primarily a tool for improving your users’ experience, allowing you to show the fields and related records that are most important for a given record type, and leave off those that are less important or unpopulated for that record type. Page layouts can be assigned for every combination of profile and record type, though admins should think hard about the justification for changing page layouts from profile to profile – does it add enough value to outweigh the additional complexity?

Page layouts offer the ability to make certain fields read-only or required, and you can leave sensitive data off entirely, though the user may still be able to access this data via reports. If a user lacks read access to a field that is set as a part of the page layout they are viewing, that field and its label will not appear, and other fields will flow up to fill the space that it occupied.

Example

Here are the specifics of setting up Salesforce for a situation like what I’ve described above. We will focus on the Contact object. In this nonprofit organization, there are two types of contacts that need special handling: Donors may be viewed, but not edited by all staff users. The Opportunity object (where donations are recorded) and the Total Donations field on the contact may only be seen by the Development department, who are also allowed to edit contacts with record type “Donor.” Contacts of type “Applicant” and the custom object “Job Applications” may only be viewed by Human Resources and the Management Team. “Standard”-type contacts may be viewed and edited by all staff. We will set up this access using a single profile for all staff, and add permission sets and sharing rules to provide the access to applicants and donors.

This should provide the basics of a security regime for a small-to-medium sized nonprofit organization. These concepts could be carried over to Leads and Accounts, and other objects and fields that need to be restricted in your organization.

Object and Field Access

1. Set up a Staff profile. It is usually easiest to clone an existing profile, like Standard. (Setup>Manage User>Profiles). Under Object Settings, disable access to Opportunities and Job Applications. Under the Contact object, disable all access to the field Total Donations, and unclick all Record Types except ‘Standard,’ which will also be the default record type. Check to make sure other object settings match your organization’s needs.
2. Set up a permission set for Development, and edit the Object Settings to give read/edit/create/delete access to the Opportunity Object, as well as read access to the Total Donations field (assuming it is a roll-up, and cannot be edited.) Use the description field to document the access provided by this permission set. It’s a hassle now, sure, but it will save time later.
3. Set up a permission set for Hiring, and edit the Object Settings to give read/edit/create/delete access to the Job Application object. Be sure to add a description.

Sharing Settings

1. Set up four public groups: Development, Human Resources, Upper Management, and All Staff. All Staff will contain all staff members, and will be used for providing read-only access to Donors to staffers outside of Development. Public Groups are found under Setup>Manage Users>Public Groups
2. Set the organization-wide sharing setting for Contacts to Private, under Setup>Security Controls> Sharing Settings.
3. Still working under Sharing Settings, we’ll set up several contact sharing rules. If Contacts was not previously set to Private, it may take a few minutes for the related list for Contact Sharing Rules to appear.
   1. Create a New Contact Sharing Rule, and give it a name. Select Rule Type Based on Criteria, then set the criteria to Contact Record Type equals Standard, then Share with > Public Group > All Staff, and change Contact Access to Read/Write
   2. Repeat this process to give Read Access to Contact Record Type equals Donor to all staff, Read/Write Access for Contact Record Type equals Donor to Development, Read/Write Access for Contact Record Type equals Applicant to Human Resources, and  Read/Write Access for Contact Record Type equals Applicant to Upper Management

Set Up Users

1. New users will need to be assigned the basic Staff profile, added to All Staff and other relevant groups, and have permission sets added. You should log in as each user type and check access by searching for Contacts of the various types.
2. Document user setup, including the public groups and permission sets for new users from each team.

Resources

Salesforce offers a wide variety of resources to educate yourself on data security, most of which are listed in this Power of Us resource document.

You should be learning using Salesforce’s fabulous trailhead tool. Here’s a direct link to the Data Security Tools module.

The Power of Us Hub is a community of nonprofit users and admins sharing knowledge. There is a Data Security group there.

Acknowledgements

Thanks to the members of the Power of Us Hub who helped me in my thinking as I pulled this article together, and offered suggestions to the text, including Olga Loza, Jon Michael Varese, Mary Pustejovsky, Steve Molis, Jonathan Spink, and Bob Bailey.