Salesforce has been revolutionary in making the customer journey understandable across departments and teams. A customer relationship management software, Salesforce gives everyone visibility of the customer at all points of interaction with the brand—from sales and marketing to customer service.
Through its 360 platform and integrations with customer-facing applications such as Mailchimp, Google Suite, and company social media accounts, Salesforce makes engaging with end-users accessible on any device, making it easy to connect with the "why" behind your business.
Moreover, Salesforce enables greater internal collaboration. With a single point of departure, gone are the days of misunderstanding the consumer from differing points of view. Having all customer data at your fingertips makes for less time wasted discussing and more time responding to their needs. It can also gather data to generate insights to sharpen your next moves to delight your customer even more.
With its many features, Salesforce users gain access to many intricate functions for their sales organization. It is also built to ensure top-notch user experience and security are upheld fo rusers and non-users. However, it can be difficult to leverage this database's full potential without sound knowledge of the basics.
All Salesforce users enter the portal and perform tasks through labels such as Profiles and Permission Sets. These names are foundational to the use of the application, as it is through these users that Salesforce records are created, made visible, and made editable.
But what's the difference between a profile and a permission set, and how do we create these in the Salesforce application? We delve into the basic functions behind profiles and permission sets, how to set these up, and how your organization can use these to its advantage.
What Is a Profile?
A profile gives users select abilities among objects within the Salesforce portal. These general tasks canbe easily remembered through the acronym CRED: Create, Read, Edit, and Delete.
A profile can create a combination of these tasks. For example, Profile 1 would be able to create and read data entries, while Profile 2 can edit and delete. Task combinations can intersect among profiles, and a profile doesn't need to possess a unique combination of tasks. While a profile can have many users, each user can only have one profile.
Profiles are usually segmented across departments or team levels like in their bubbles. Think of the differing needs of a sales vs. a marketing profile or an entry-level against a middle management-level profile. Sorting access into profiles helps administrators effortlessly limit the level of confidentiality allowed by certain employees—since one profile applies to the entire team, team-wide access can be confirmed or denied with a few clicks.
Profiles also help to appropriate access within and among teams. For example, an entry-level HR manager’s profile might be able to create new employee data, but because of the level of confidentiality needed, only their bosses’ profiles would be able to read and edit these. Data deletion would only be restricted to the HR lead.
Profiles come in two types: the Standard Profile made by Salesforce, and the Custom Profile, which the user makes. Across all users, there is the "Mega User," also known as the “System Administrator.” This user profile has all access functions, including mass viewing, modifying, and deletion. It can even customize the application as you know it.
Aside from dealing with object data, profiles may also be able to influence security, layouts, types of records, and others.
How to Create Profiles
To create a standard profile:
- At Salesforce.com, go to Setup > Administer > Manage Users > Profiles.
- At the new window, click “Select New Profile.”
- Enter a profile from the list and match it to a user license.
- Name your profile.
- Click Save.
For Custom profiles, you can clone a user profile, assuming access rules are aligned:
- At Salesforce.com, go to Setup > Enter “Profiles” on the Quick Find box.
- Click New Profile and choose a profile you want to clone.
- Click Clone. Note that the new profile uses the same user license as the profile it was cloned from.
- Enter a profile name.
- Click Save.
What Is a Permission Set?
A Permission Set is a more specific set of commands which give users exclusive access to certain tools and functions. This allows users to extend their access without having to change their profiles.
Unlike profiles, permission sets are not entirely necessary to enter into Salesforce, but they should be leveraged to maximize the use of the application. Similar to creating an individual user, permission sets make you unique in Salesforce —minus having to make your profile from scratch.
Permission sets are necessary because of a rule of thumb in data security called organization-wide defaults. For everyone's safety and the data manager's peace of mind, it is much easier to set the strictest restrictions across the entire organization and issue exceptionals on a case-to-case basis via permission sets. This way, all possible loopholes are denied access instead of the other way around.
While users can only have one profile, a profile can be assigned multiple permission sets depending on the specific user. Assuming all user licenses are constant, a permission set can beassigned to any profile—meaning the sales director's profile is just as eligible for a permission set as the new hire's.
Permission sets are a great way to assign tasks to specific people or groups per team. Take line managers as an example. All line managers ought to have visibility in the career paths of their managers. In this case, a permission set would be engaged to allow viewing access of employee data to all team leads across departments. Their differing profiles would prohibit them from having the same functionalities otherwise.
Using the permission set functionality is also useful to allow access among users who may not normally need access in their usual profile. For example, users cannot normally change their password settings but can do so once they enable the permission set, saying they forgot their password.
How to Create and Use Permission Sets
To create a permission set:
- At Salesforce.com, go to Setup > Enter “Permission Sets” on the Quick Find box.
- Click on New.
- Input your desired permission set information.
- Choose the user license applicable for the permission set. For example, choosing the Salesforce license for a permission set makes the set accessible only by those with the Salesforce license.
Note that the user license feature allows you to easily dispatch the permission set across similar users. But if the desired user base has no common license assigned to them, you have the option to click None. Doing so allows your permission set to be assigned to any user when needed.
To assign permission sets to users:
- At Salesforce.com, go to Setup > Enter “Users” on the Quick Find box.
- Select a user.
- Under permission set assignments, click on Edit Assignments.
- Select a permission set and assign it under Available Permission Sets.
- Click Add.
- Don’t forget to Save.
To remove a permission set assignment, go through Steps 1 to 3, select the permission set under Enabled Permission Sets, and click Remove. And don’t forget to save!
A simpler way to ensure data security is to anchor permission sets on objects rather than users. Think of the permission set as a vault encasing the object, and only those with theright key can have access.
To assign object permission sets:
- At Salesforce.com, go to Setup > Enter “Users” on the Quick Find box.
- Select a permission set.
- In the Find Settings box, type in an object and select it from a list.
- Click Edit and move to the Object Permissions section.
- Indicate the object permissions, and click Save.
Bonus: What Is the Permission Set Assignments Page?
The permission set assignments page shows the universe of all applicable permission sets for a specific user. This page comprises permission sets assigned to the user's license and permission sets without any license assignment.
For example, suppose a user is assigned to the Service Cloud Portal User Licenses. In that case, he gains access to permission sets allowed by this user license, such as creating support tickets and viewing customer information. Likewise, he can also access generic permissions open to all employees, such as viewing product data.
It’s important to check that the user’s license is compatible with the permission set’s features and settings. Otherwise, the permission set assignment will fail.
To access the permission overview page:
- At Salesforce.com, go to Setup > Enter “Permission Sets” on the Quick Find box.
- Select the permission set you want to view.
An Example of Why Both Are Needed
A profile can be seen as the base by which a user in Salesforce comes to be. It determines the minimum basic tasks a user can perform in the application and cannot be changed individually. These are best to establish a group or team setting.
Permission sets are then built on the base through additional access settings as users and among objects, creating a unique online identity. These can be added or removed from “Available Permission Sets” to “Enabled Permission Sets.”
Together, profiles and permission sets allow the right balance between data security and seamless functionality. They allow the right users to have all the needed access right when needed.
Here’s a summary of the two:
<table>
<tbody>
<tr>
<td>
<table width="589">
<tbody>
<tr>
<td width="139">
<p> </p>
</td>
<td style="text-align: center;" width="246">
<p><strong>Profile</strong></p>
</td>
<td style="text-align: center;" width="205">
<p><strong>Permission Set</strong></p>
</td>
</tr>
<tr>
<td width="139">
<p><strong>Purpose</strong></p>
</td>
<td width="246">
<p>Establishes objects which are given access and actions which can be performed on them</p>
</td>
<td width="205">
<p>Gives additional access settings</p>
</td>
</tr>
<tr>
<td width="139">
<p><strong>Scope</strong></p>
</td>
<td width="246">
<p>Same across all users </p>
</td>
<td width="205">
<p>Fully customizable per user</p>
</td>
</tr>
<tr>
<td width="139">
<p><strong>Quantity</strong></p>
</td>
<td width="246">
<p>Only one per user</p>
</td>
<td width="205">
<p>Multiple per user</p>
</td>
</tr>
</tbody>
</table>
</td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td> </td>
<td> </td>
<td> </td>
</tr>
</tbody>
</table>
Let’s see these laid out in an example of a Salesforce application of a field service company. Field service companies comprise field maintenance specialists dispatched to conduct surveys and repairs, office agents coordinating with the customer on concerns and updates, and area managers in charge of entire repair teams.
Coming from the same team, let's presuppose the entire team has the same user profile. All users can only read work order data using the org-wide default. This ensures transparency on all the support tickets logged in the system. The rest of the functionalities can be executed in permission sets specific to each team member:
●As the receiver of customer calls, only the office agent can create new work orders, which serve as a basis for the field maintenance specialists' routes for the day.
●Since they are the only ones on site, only the field maintenance specialists can edit the work order based on the work done during the visit, with the customer's sign-off.
●For any exceptional cases, only the area manager would be allowed to override the ticketing system and delete work orders—which must also be substantiated with customer approval.
As such, in the case of work orders, this is how access looks in this field service organization:
<table width="533">
<tbody>
<tr>
<td width="199">
<p> </p>
</td>
<td width="95">
<p><strong>Create</strong></p>
</td>
<td width="78">
<p><strong>Read</strong></p>
</td>
<td width="66">
<p><strong>Edit</strong></p>
</td>
<td width="95">
<p><strong>Delete</strong></p>
</td>
</tr>
<tr>
<td width="199">
<p><strong>Office Agent</strong></p>
</td>
<td width="95">
<h2 style="text-align: center;">✓</h2>
</td>
<td style="text-align: center;" width="78">
<h2> ✓</h2>
</td>
<td width="66">
<h2> </h2>
</td>
<td width="95">
<h2> </h2>
</td>
</tr>
<tr>
<td width="199">
<p><strong>Field Repairman</strong></p>
</td>
<td width="95">
<h2> </h2>
</td>
<td width="78">
<h2 style="text-align: center;"> ✓</h2>
</td>
<td width="66">
<h2 style="text-align: center;"> ✓</h2>
</td>
<td width="95">
<h2> </h2>
</td>
</tr>
<tr>
<td width="199">
<p><strong>Area Manager</strong></p>
</td>
<td width="95">
<h2> </h2>
</td>
<td width="78">
<h2 style="text-align: center;"> ✓</h2>
</td>
<td width="66">
<h2> </h2>
</td>
<td style="text-align: center;" width="95">
<h2> ✓</h2>
</td>
</tr>
</tbody>
</table>
<p> </p>
While the example is only about one item, imagine how the play between profiles and permission sets can be executed across various data objects in the organization.
The example shows the functionality of executing permission sets per member and how differing access functions can be placed to keep data secure. No person can do all functions to prevent fraud and keep the customer at the center of each move.
Conclusion
Knowing the strengths of profiles and permission sets is essential to utilizing the Salesforce platform fully. Despite their similarities and differences, profiles and permission sets were made complementary features—they are meant to be used together for everyone’s safety and convenience.
