Control Access to Objects
Learning Objectives
After completing this unit, you’ll be able to:
- Explain the difference between profiles, permission sets, and permission set groups.
- Modify access to objects.
- Clone and assign a profile.
- Create and assign new permission sets.
- Create and assign new permission set groups.
Manage Object Permissions
The simplest way to control data access is to set permissions on a particular type of object. (An object is a collection of records, like leads or contacts.) You can control whether users can create, read, edit, or delete any records of that object.
We recommend that you set object permissions with permission sets and permission set groups, though it’s also possible to configure object permissions in profiles. What’s the difference between these features?
-
Permission sets: Used to assign object, field, and user permissions to users. We recommend that you organize your permission sets by including all the permissions required for a finite task, such as working with leads. Users can be assigned multiple permission sets.
-
Permission set groups: Used to group multiple permission sets together for easier management. Think of permission set groups as representing a “persona” in your org, like a Sales Rep. Users assigned to the permission set group receive all permissions in the included permission sets. Users can be assigned multiple permission set groups. And permission sets can be reused in different permission set groups, making it easier to manage access.
-
Profiles: Used to configure user’s default settings, such as assigned apps, record types, page layouts. Users are assigned one profile.
For more information see Guidelines for Creating Permission Sets and Permission Set Groups in Salesforce Help. As you can see, these features give you a great deal of flexibility in specifying object-level access. You see in this unit how to set up these features for your Recruiting app to make sure your users have the correct access to objects.
Object Permissions for the Recruiting App
Let’s explore how you configure object-level access in the Recruiting app. The app has four main types of users: hiring managers, recruiters, interviewers, and standard employees. What access to objects does each type of user need?
Hiring Managers
Ben, a hiring manager, should be able to access recruiting records related to his open positions, but shouldn’t have access to other recruiting records (unless they’re owned by other hiring managers who report to him). Also, there are certain sensitive fields that he has no need to see, like the social security number field. Consider the permissions Ben needs for each of the key custom objects in the app.
-
Position: Ben should be able to post new positions, as well as update and view all fields for positions for which he’s the hiring manager, but he should only be able to view other managers’ positions.
-
Candidate: Ben should only be able to view those candidates who have applied for a position for which he’s the hiring manager. Also, since Ben has no reason to see a candidate’s social security number, this field should be restricted from his view.
-
Job Application: Ben needs to be able to update the status of job applications to specify which candidates should be selected or rejected. However, he should not be able to change the candidate listed on the job application, nor the position to which the candidate is applying, so you have to find a way of preventing Ben from updating the lookup fields on job applications.
-
Review: To make a decision about the candidates who are applying, Ben needs to see the reviews posted by the interviewers, as well as make comments on them if he thinks the interviewer was being too biased in his or her review. Likewise, Ben needs to be able to create reviews so that he can remember his own impressions of the candidates he interviews.
Recruiters
Mario, a recruiter, needs to be able to create, view, and modify any position, candidate, job application, or review that’s in the system. He also needs to view and modify the recruiting records that all of the other recruiters own, since all the recruiters work together to fill each position, regardless of who created it.
You need to make sure a recruiter can never accidentally delete a record with information about a candidate. That’s because state and federal laws require recruitment-related records be saved for a number of years, so that if a hiring decision is questioned, it can be defended in court.
Interviewers
Melissa is an engineer who interviews candidates for highly technical positions. She should be able to view only the candidates and job applications to which she’s assigned as an interviewer. Also, she shouldn’t be able to view the minimum and maximum bonus values for any of the positions or the social security number of any candidate, as that’s sensitive information that has nothing to do with her job.
Standard Employees
Employees, such as Harry, are often the best resources for recruiting new hires, even if they aren’t active hiring managers or interviewers. For this reason, you need to make sure that employees can view open positions, but that they can’t see the values for the positions’ minimum and maximum bonus fields. Harry also shouldn’t be able to view any other records in the Recruiting app.
Here are the required permissions for each of the four types of users.
Custom Object
|
Recruiter
|
Hiring Manager
|
Interviewer
|
Standard Employee
|
---|---|---|---|---|
Position |
Read Create Edit |
Read Create Edit* |
Read (No min/max bonus) |
Read (No min/max bonus) |
Candidate |
Read Create Edit |
Read* (No SSN) |
Read * (No SSN) |
Not Applicable |
Job Application |
Read Create Edit |
Read Edit (No lookup fields) |
Read * |
Not Applicable |
Review |
Read Create Edit |
Read Create Edit |
Read ** Create Edit ** |
Not Applicable |
*Only for those records that are associated with a position to which the hiring manager or interviewer has been assigned.
**Only for those records that the interviewer owns.
In the rest of this module, you learn how you can use the platform to implement these requirements in the Recruiting app. This requires configuring security controls at all three levels: objects, fields, and records.
Setting Up Profiles
As you learned earlier, each user has a single profile, which is associated with a user license. The platform includes a set of standard profiles with predefined settings. Some examples are:
- Standard User
- Marketing User
- Contract Manager
- System Administrator
- Minimum Access - Salesforce
Each standard profile includes a default set of permissions for standard objects available on the platform. For example, a Standard User can create and edit records while a Minimum Access - Salesforce user can view records, but not create or edit them. The System Administrator profile has the widest access to data and the greatest ability to configure and customize Salesforce. In particular, the System Administrator profile includes two special permissions, View All Data and Modify All Data. These permissions override all other sharing settings, so use caution when assigning them to any profile other than System Administrator.
It’s likely that some standard profiles contain more access than your users require, especially if you’re following the security best practice of using permission sets and permission set groups to configure access. Make sure to review what permissions and settings each profile contains before assigning it to users.
You can’t edit the object permissions on a standard profile. However, you can clone any existing profile, and use that as the basis for a new profile, adjusting settings as needed. Whenever possible, we recommend that you use the Minimum Access Salesforce profile (or a clone of it), and then use permission sets and permission set groups to grant users only the permissions that they require. For example, in the Recruiting app, you can assign recruiters, interviewers, and hiring managers the Minimum Access - Salesforce profile, despite their different job functions. This profile grants very limited permissions and abilities in the Salesforce Platform, but you can grant additional access using permission set and permission set groups.
Create and Assign a Profile
The easiest way to create a profile is to clone an existing profile that’s similar to the one you want to create, and then modify it. For example, you want a slightly modified version of the Minimum Access - Salesforce profile with different default apps visible.
Salesforce has an enhanced profile user interface that makes it easy to find and modify profile settings. That’s what you use for this exercise.
- From Setup, in the Quick Find box, search for and select User Management Settings.
- Enable Enhanced Profile User Interface.
- From Setup, in the Quick Find box, search for and select Profiles.
- Click Clone next to a profile similar to the one you want to create.
- Give your new profile a name, and click Save.
- Edit the profile’s default settings as required, and click Save.
- From Setup, in the Quick Find box, search for and select Users.
- Click Edit next to the user that you want to assign the profile to.
- In the Profile dropdown, select the profile that you just set up.
- Click Save.
Use Permission Sets and Permission Set Groups to Grant Access
Earlier, you learned that permission sets and permission set groups are the preferred way to manage your users’ permissions and access. Let’s take a closer look as to why.
A permission set is a collection of settings and permissions that give users access to various tools and functions. Permission set groups are what they sound like–groups of permission sets! Permission sets make it easy to grant access to the various apps and objects in your org (and to take away access if it’s no longer needed) because of their flexibility and reusability. Because you can reuse smaller permission set building blocks, you can avoid creating dozens or even hundreds of profiles for each user and job function.
Create permission sets that include all permissions necessary for a job or task. Then bundle these permission sets into permission set groups that correspond to your user personas. If different personas perform some of the same tasks, you can reuse those permission sets in different permission set groups.
For example, let’s say you have both Sales Reps and Marketing Specialists who must delete and transfer leads. You can create a permission set based on lead management. Then, include the permission set within the “Sales Reps” and “Marketing Specialists” permission set groups based on the users’ roles. For additional permissions related just to Sales or Marketing, you can create permission sets to include in their respective permission set groups.
Configure these permissions and features in permission sets.
- Apex classes
- Connected app access
- Custom permissions
- Field permissions
- Object permissions
- User permissions (app permissions and system permissions)
- Tab settings
- Visualforce pages
Permission Sets and Permission Set Groups for the Recruiting App
Now that you know about permission sets and permission set groups, think about how to set up object-level access for the example Recruiting app. The app has four main types of users: recruiters, hiring managers, interviewers, and standard employees.
Recruiters
These represent a clearly defined job function, so it makes sense to create a Recruiters permission set group. For access to recruiting data (reviews, candidates, positions, and job applications), you create separate permission sets related to the tasks for each of these objects.
Hiring Managers
It’s possible that a hiring manager in Sales needs access to a different type of data than a hiring manager in Engineering. However, all hiring managers still need the same type of access to recruiting data via object permissions. For this reason, we recommend creating a Hiring Manager permission set group that can be assigned to various types of users. You take care of more specific restrictions, like field-level security and record access, later.
Interviewers
An employee from any department and in any job function might be called upon to perform an interview and requires access to recruiting information only for a limited amount of time. It makes sense to define a permission set group for Interviewers, and assign and remove users as needed.
For reviews in particular, recruiters, hiring managers, and interviewers all require Read, Create, and Edit permissions for the Review object. To save effort, you can reuse the same permission set in all of these job functions’ permission set groups!
Standard Employees
Remember that employees not involved in recruiting should still be able to see positions. Because this is a company-wide requirement, consider creating a baseline permission set that gives more limited read access to positions. Then, include this permission set in persona-specific permission set groups, making sure all users receive this access in some way.
So, with all these permission scenarios in mind, the optimal way to configure object permissions for the Recruiting app is like this:
- Create three permission set groups: Recruiters, Hiring Managers, and Interviewers
- Create permission sets related to working with reviews, candidates, positions, and job applications. Reuse permission sets in permission set groups when possible, but make sure you aren’t granting users too many permissions.
Create a Permission Set
Create a permission set that controls access to the Review object for your Recruiter app.
- From Setup, in the Quick Find box, search for and select Permission Sets.
- Click New.
- Enter your permission set’s label and description. Name this one
Access and Manage Reviews
.
- Optionally, you can select whether only users with certain licenses are assigned this permission set. Select –None–.
- Click Save.
- To add object permissions, in the Find Settings box, search for and select Reviews.
- Click Edit.
- Enable Read, Create, and Edit permissions.
- Click Save.
You can assign permission sets directly to users. But instead, first create a permission set group and include this permission set.
Create a Permission Set Group
For your Recruiter app, you determined that all three persona-based permission set groups contain the same object permissions for reviews. Create the permission set group for Recruiters.
- From Setup, in the Quick Find box, search for and select Permission Set Groups.
- Click New Permission Set Group.
- Enter your permission set group’s label (in this case,
Recruiters
) and description.
- Click Save.
- On the Recruiters permission set group’s overview page, click Permission Sets in Group.
- Click Add Permission Set, then select the checkbox for the Access and Manage Reviews permission set.
- Click Add, then click Done.
The Recruiters permission set group is configured and grants access to reviews. The final step is to assign it to users.
- On the Recruiters permission set group’s overview page, click Manage Assignments and then Add Assignment.
- Select the users to assign to the group, and then click Next.
- Optionally, select an expiration date for the user assignment to expire. This option can be useful if you want users to be assigned the permission set group temporarily.
- Click Assign.
Review Access Using Summaries
As you set up access for all of your objects, you might find that it’s a lot to keep track of. Which permission sets grant access to accounts? Does Joe Smith have the ability to delete leads? To help you review and manage permissions, you can use Salesforce summaries on object access, user access, permission sets, and permission set groups.
For example, in Object Manager, you can see the permission sets, permission set groups, and profiles that grant access to an object, and the level of access granted.
- From Setup, go to Object Manager.
- Select an object that supports object permissions.
- In the sidebar, click Object Access.
You can also see all object, field, and user permissions that a user is assigned and how that access is granted.
- From Setup, in the Quick Find box, search for and select Users.
- Select a user.
- Click View Summary.
Finally, you can easily see all permissions included in a permission set or permission set group from their summary pages.
- From Setup, in the Quick Find box, search for and select Permission Sets. Or, in the Quick Find box, search for and select Permission Set Groups.
- Select a permission set or permission set group.
- Click View Summary.
Well done! By assigning object permissions, you took the first step to managing data access. In the next units, you fine tune this data access by setting restrictions on fields and records.
Resources
- Salesforce Help: Manage Users and Data Access
- Salesforce Help: Object Permissions
- Salesforce Help: Configure Default Settings in Profiles
- Salesforce Help: Configure Permissions and Access in Permission Sets
- Salesforce Help: Permission Set Groups
- Salesforce Help: View Object Access in Object Manager
- Salesforce Help: View a User’s Access Summary
- Salesforce Help: View Permissions Enabled in a Permission Set or Permission Set Group