Control Access to Objects
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 a group of users can create, view, edit, or delete any records of that object.
- 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.
Use profiles to grant the minimum permissions and settings that all users of a particular type need. Then use permission sets to grant more permissions as needed. The combination of profiles and permission sets gives you a great deal of flexibility in specifying object-level access.
Object Permissions for the Recruiting App
As an example, let’s explore how you might configure object-level access in the Recruiting app. (Note that since this is an example, you won't see this app in your org!) The app has four main types of users: hiring managers, recruiters, interviewers, and standard employees. What kinds of access to objects does each type of user need?Hiring Managers
Ben, a hiring manager, should be able to access the 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. Let’s 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 on 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 we'll 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.
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.
We need to make sure a recruiter will 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.
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 salary 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.
Employees, such as Harry, are often the best resources for recruiting new hires, even if they are not active hiring managers or interviewers. For this reason, we need to make sure that employees can view open positions, but that they can't see the values for the positions' minimum and maximum salary fields—otherwise they might tip off friends to negotiate for a position's maximum salary value! 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 pay)||Read (No min/max pay)|
|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|
In the rest of this module, you'll learn how you can use the platform to implement these rules in the Recruiting app. As you’ll see, this will require configuring security controls at all three levels: objects, fields, and records.
Use Profiles to Restrict Access
- The settings in a user’s profile determine whether the user can see a particular app, tab, field, or record type.
- The permissions in a user’s profile determine whether the user can create or edit records of a given type, run reports, and customize the app.
Profiles usually match up with a user's job function (for example, system administrator, recruiter, or hiring manager), but you can have profiles for anything that makes sense for your Salesforce org. A profile can be assigned to many users, but a user can have only one profile at a time.
The platform includes a set of standard profiles. Some examples are:
- Standard User
- Marketing User
- Contract Manager
- System Administrator
- Minimum Access - Salesforce
- View All Data
- Modify All Data
These permissions override all other sharing settings, so use caution when assigning them to any profile other than System Administrator. You can view a list of all standard and custom profiles in Setup.
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 the apps and system settings as needed. For example, in the Recruiting app, you might create three new profiles, one each for recruiters, interviewers, and hiring managers. Each profile can then be configured to provide the specific type of data access required for a particular role. You can then use permission sets to grant additional permissions, as required.
The profile overview page provides an entry point for all of the settings and permissions for a single profile. In Setup, use the Quick Find box to find Profiles and click the profile you want to view.
Create a Profile
- In Setup, use the Quick Find box to find Profiles.
- Click Clone next to a profile similar to the one you want to create.
- Give your new profile a name, and save.
Assign a Profile
- Find Profiles in Setup.
- Click the Profile Name for the profile you want to change permissions for. The Profile Overview displays.
- Set the most restrictive settings and permissions you can for this user type, and save. (Don’t worry about blocking the user from doing things they need to do. We'll open up more possibilities for them later, when we give them permission sets.)
- Find Users in Setup and click the Edit link next to one of them.
- From the Profile dropdown select the profile you just set up. Then click the Save button.
Use Permission Sets to Grant Access
Grant access to custom objects or apps.
Let’s say you have many users in your org with the same fundamental job functions. You can assign them all one profile that grants them all the access they need to do their job. But a few of those users are working on a special project and they need access to an app no one else uses. And a few other users need access to that app, as well as another app that the first group doesn’t need. If we only had profiles, you’d have to create more profiles customized to those few users’ needs, or take your chances and add more access to the original profile, making the apps available to users that don’t need them. Neither of these options is ideal, especially if your org is growing and your users’ needs change regularly.
Grant permissions to specific fields.Let’s say you have a user, Tom, who needs temporary edit access to a field while his co-worker is on vacation. You can create a permission set that grants access to the field and assign the permission set to Tom. When Tom’s co-worker returns from vacation and Tom no longer needs access to the field, you just remove the permission set assignment from Tom’s user record.
Managing Permission Sets
A permission set’s overview page is the entry point for all of the permissions in a permission set. To open a permission set overview page, find Permission Sets in Setup, then select the permission set you want to view. In each permission set, permissions and settings are organized into app settings, system settings, object permissions, and field permissions.
Create a Permission Set
- Use the Quick Find box to find Permission Sets in Setup.
- Click Clone next to the set you want to copy. A cloned permission set has the same user license as the original. To create a set with a different license, click New (1) instead.
- Enter a label and a description. The API name is a unique name used by the API and managed packages. It automatically replicates the label, but you can modify it.
- If this is a new permission set, select a user license option.
- If you plan to assign this permission set to multiple users with different licenses, select --None--.
- If only users with one type of license will use this permission set, select that user license.
- Click Save to go back to the permission set overview page.
- In the permission set toolbar, click Manage Assignments, then click Add Assignments.
- Select the users to assign to this permission set and click Assign. Review the messages on the Assignment Summary page. If any users weren’t assigned, the Message column tells you why.
- Click Done to return to a list of the users assigned to the permission set.
Profiles and Permission Sets for the Recruiting App
These represent a clearly defined job function, and they need access to different types of data than other users. Hence, it makes sense to create a profile for recruiters.
For most orgs, a hiring manager in Sales will need access to a different type of data than a hiring manager in Engineering. However, all hiring managers still need the same types of access to recruiting data—reviews, candidates, positions, and job applications. Hence, it’s convenient to create a hiring manager permission set that can be assigned to various types of users.
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 for interviewers, since permissions can be easily assigned and revoked as needed.
This is a generic group that doesn’t reflect a particular job function. For most employees, you can create a base profile that provides access to a small set of data, and then depending on what their specialties are, create and assign permission sets to give them more access as needed.
So from what we've seen, the optimal way to configure object permissions for the Recruiting app is like this:
- Create two profiles: Recruiters and Standard Employees.
- Create two permission sets: Hiring Managers and Interviewers.
- Assign the Standard Employee profile to hiring managers and interviewers, and then grant the appropriate permission set for their function.