Permissions – Where do I start?

Are your employees unable to access the new application you built for them? Are your managers unable to see the work of the employees they manage? Are your customer service teams struggling to collaborate together on a case? If any of these situations apply to you, you may have permission issues within your Salesforce org.

One of the most complex areas of Salesforce is user permissions. User permissions define what Objects or records a user can access and edit. The core building blocks of user permissions are Profiles, Permission Sets, and Org-wide Defaults. Properly configuring user permissions can be a lot to handle for a new Salesforce Admin. It can also be a major stumbling block for those desiring to learn how the Salesforce platform works. Let’s take a minute to overview the different permission structures within Salesforce and how each level of access works.

The first thing to understand in Salesforce is the difference between Object-level access, field-level access, and record-level access.

Let’s start simple. Object-level access is the most basic level of access needed to view a record within Salesforce. If a user doesn’t have access to the Case Object, that user will not be able to view any Case records coming in from concerned customers. Object-level access is needed before a user is allowed to view or access anything on an object.

Going a step further, field-level access is the ability to see or edit fields on Object records. Needless to say, Object-level access is useless without some form of field-level access. The two go hand-in-hand. Most of the time, general field-level access is granted alongside Object-level access, so the user can access the Object and view the majority of fields on said Object. Field-level access is often customized per user. Those in the finance or billing department may need access to a field containing the social security number for a customer, while other non-finance users should not be able to see that confidential information. field-level access can be customized to hide the field from those not working in finance and achieve a better system of security.

Finally, we have record-level access. While a user may be able to access an Object and its relevant field, record-level access defines which particular records can be accessed. The baseline of record access is determined by what Salesforce calls “Org-wide Defaults.” Org-wide Defaults are often set per object and determine the default permissions regarding record access on that object. Record-level access can be limited or expansive. Usually, most objects are set to an Org-wide Default of “Private,” meaning users can only access records they themselves have created. However, that access can easily be changed. Maybe you have a Sales Team that needs to collaborate on Opportunities together. Maybe you need a Customer Service Manager to see all the cases being worked on by the service reps below him. Record-level access can change which particular records an individual or a team can view and edit.

I often visualize Object and field level access on a vertical plane and record-level access on a horizontal plane, much like columns and rows on an excel spreadsheet. Object-level and field-level access will allow the user to see or edit a record. Record-level access will determine which particular records a user can see or edit. Now that we’ve established the three areas of access, we need to learn how to grant that access to users.

The core unit of permission and security across all areas of Salesforce is the Profile. It will grant base-level permissions for Object, field, and record access. Users must be assigned at least one Profile upon user creation, and Profiles can easily be swapped around if more or less permission is needed. Salesforce comes with a set of default Profiles, but companies will create their own custom Profiles to better suit their particular business model and policies. This can be easily done by cloning and existing Profile and editing which Objects, fields, and records can be viewed or edited.

Permission Sets contain one or many individual permissions and can be attached to a user to grant additional access beyond what their Profile allows. It is important to note that Permission Sets will only grant additional access, they will not take away access already defined by the Profile.

Because record access is primarily defined by Org-wide Defaults, there are more than a few ways of granting additional access to records. Sharing rules are the most basic way to achieve this. They will grant users access to particular records or a set of records. They can be configured manually or automatically run based on certain criteria. Additionally, Company Hierarchies can be set up within Salesforce to create a management structure of record access. Even if an Object is given an Org-wide Default of “Private,” a Company Hierarchy can allow the sales manager to see all the records of sales reps below him.

While not as common, profiles can be used to control record access too. Having the “Modify All” permission checked on your Profile or a permission set attached to your user will allow complete access to modify nearly any record within the Salesforce org. This is usually only used for system Admins, so they can properly test new additions to the org. “View All” or “Modify All” are other permission that will achieve similar results, but on an object-to-object basis.

With any luck, this explanation should give you a better baseline of knowledge when it comes to how permission works within Salesforce. Understanding the three levels of access, and how Profiles, Permission Sets and Org-wide Defaults grant access is the first step in becoming a great Salesforce Admin. As for the specifics of setting up permissions and Profiles, it would be wise to visit Trailhead, Salesforce’s main source of interactive learning. Anyone can create a free account and take ownership of a demo Salesforce org. For information specifically on data security, start here. Happy Trailblazing!