Who Sees What Salesforce: A robust Customer Relationship Management (CRM) platform called Salesforce has proven indispensable to innumerable global organisations. They understand the complex network of access control and permissions dictating who sees what within the platform, which is essential as businesses use Salesforce to manage their customer data.

This extensive blog article will explore the intricacies of Salesforce access control, illuminating the roles, profiles, and permission settings that dictate user visibility.

In Salesforce, Who Sees What Salesforce?

Control Who Sees What

With Salesforce data sharing, you can make particular data sets available to individuals and groups of users. By limiting access, permission sets, permission set groups, and profiles offer security at the object and field levels. Users’ ability to see and edit individual records is restricted by sharing rules, user roles, and record-level sharing settings.

The deep visibility architecture enabling administrators to manage access to company information inside and outside the organization is one of the most significant characteristics of Salesforce. This control reduces the misuse or theft of data, whether it be private consumer information or confidential internal company data, and is an essential part of data security and privacy.

Organizations are intricate systems made up of numerous data layers and user profiles. Our goal in writing this blog was to address how we connect the right individual with the correct and pertinent information so they can quickly complete their work. 

Field Level Security Who Sees What Salesforce

Certain areas could contain privileged data or secret information, like commissions. Even if users can access the object records, we want to keep them from seeing the data in these fields. Field-level security is helpful in this situation. We will be able to restrict which profiles can view which record fields by using this feature. 

Field-level security overrides allow for all user profile settings to be viewed and modified. 

Example: We want to restrict who can view the commissions that our sales representatives have posted in the Opportunity Record. Click the Opportunity object from the Object Manager. We pick the commission Field by clicking Fields and Relationships. The field-level security button at the top of the page is then connected.

We would like to safeguard the Commission on our client’s opportunity record in this instance. To create this field restriction, we can uncheck the “Visible” tick next to the Sales Rep User profile.

Sales representatives won’t be able to see the Commission field on their records, even though that user profile has View and Edit permissions on this item. Our private information is now shielded from possible abuse.

Use sharing rules to record access. 

When the Org-Wide settings are more restricted than public read/write, sharing rules provide access to records. Stated differently, sharing rules give users access to roles, public groups, and territories irrespective of their position within the role hierarchy.

Three kinds of sharing rules exist: public groups, criteria, and record owner-based.

Based on: Record Owner  

A larger audience of roles and subordinates than those allowed by the role hierarchy can access records.

For instance, sales managers must be able to view the opportunities that sales teams in other territories or regions own. We use Record Owner to inform the creation of an Opportunity sharing rule. We include the US Sales Manager and his staff in the Records to be Shared field. 

We include the sales manager from the other territory on the users to share with. We click save after choosing to allow read-only or read-write access.

Standards-based: The sharing of records depending on the value in an object’s field is made possible by criteria-based sharing.  

For example, All Cases with “Company Benefits” listed in the Type field should be accessible to our HR Benefits Coordinator. Using this criteria-based sharing rule, the benefits coordinator can view the benefits queries submitted to the HR division. Still, not every case submitted to the department will be fully accessible to the user. 

Public Associations: Users who are not necessarily in the same role or group but share something in common make public groups. Consider members of Public Groups to be individuals with similar interests but different roles. 

For example, a volunteer group from our organization works at several charities throughout the city. Volunteers in the organization come in different ranks and roles. These individuals can exchange tasks, events, and contacts related to the charities by setting up a Public Group. 

Types of Records 

Thanks to Record types, that have control over the page layouts, picklist values, and business processes that our representatives may access. 

Salesforce’s Record Types allow us to divide the accessible data to our users based on their potential sales routes. Since separate sales representatives handle sales to small and medium-sized businesses and sales to enterprises and have various fields and sales processes, we can build multiple record types for each type of business in this example. 

Before accomplishing this, we must pre-define each business unit’s opportunity stages and sales processes. Page layouts can be copied and modified for this particular use case or shared from other record types you currently have in place. 

Choose the item for which you want to create a record type in the item Manager, then click on the Record Type settings. Give the record type a name, then assign it to the appropriate Profiles, and a sales process is explicitly created for it.

Give this business unit the Page Layouts that you designed. You can also create a fresh page layout and apply it to this record type.

That’s all there is to it. You have successfully developed a Record Type that will enable users to accomplish their tasks by controlling how they interact with your organization and its data.

Permission sets

We can give users more access and permissions than specified in their profile by using permission sets. Consider permission set as a supplement to the profile, which you can apply as a further layer to particular users who require specialized access to precise Records and Apps to carry out their job responsibilities.

When you have a subset of users in a profile who require slightly greater access to particular records than the rest of their team, the permission set use case shines. Additionally, users can be allocated many permission sets, making it easier to control a single user’s access based on their job responsibilities rather than creating new profiles for every scenario.

Example: Select supervisors within our organization are in charge of hiring new team members. Rather than making a separate profile just for these managers, we can use a Permission Set to allow them access to the Recruiting App. Access to sensitive fields on the applicant record, such as salary requirements, and the additional capability to examine objects not included in the Standard Manager Profile can also be enabled by creating a separate permission set. These two sets of permissions allow us to modify the level of access that different hiring and recruiting users have. 

We may add or remove these permission sets from the user record without affecting the primary user profile of the manager as their duties change.

Control Who Sees What in Loyalty Management

Loyalty Management is enabled in your organization by your Salesforce admin. Users can edit records and loyalty items when this feature is enabled. When suitable, users can provide permission to use loyalty applications and create profiles.

Profiles of Loyalty Management: Users’ access to objects and data is defined by their profiles, which also control what they can do within the application. You can make a regular profile or copy one to use the loyalty program.

Give Loyalty Management Access: To grant your users modified access to the Loyalty Management Objects, utilize the Loyalty Management permission set.

Loyalty Management Permissions: Grant authorization for user interface actions, connected APIs, and invocable actions. Utilize sharing rules to distribute and manage user access to loyalty records.

Implement Security at the Field Level for Loyalty Management: You can limit users’ ability to view and update particular fields by implementing field-level security settings.

In summary

Secure and effective data handling is based on Salesforce’s strong authorization and access control mechanism. This blog article aimed to clarify Salesforce’s complex network of roles, profiles, permission sets, record kinds, sharing rules, and criteria-based sharing.

Administrators must have a thorough understanding of these access control techniques to guarantee that the appropriate users view the correct data at the proper time as firms continue to leverage the capabilities of this massive CRM system.