Salesforce Record Level Access: Salesforce Sharing Setting

In Salesforce we can control user access on many levels. Let’s see all Levels of Accesses for a user in salesforce org.

Access Levels

• Organization Access.
• Object And Fields Access.
• Record Access.
• Permission Sets

1-Organization Access

To begin, the user must be granted access to log in to the Salesforce organization.

We need to look into whether the user has a trusted IP Address.

In Order To make our organization secure, we set the trusted IP range on two levels.

• Company Level IP Range.
• Profile Level IP Range.

Company-Level IP Restriction

• If a user has an IP address that is not in the range of company IP Address range then while trying to log in, the user will be sent an activation code. They can log in once they’ve entered the code.

Path in salesforce to restrict and add IP range.
Setup>Security>Network Access

Company Level IP Access works until we set the IP range at the profile Level.

Profile-Level IP Restriction

Go to setup>Profile>open users profile>find Login IP range>Click New.

• Now set an IP range here and Save.
• By specifying the IP range here, at the profile level, anyone with this profile trying to log in from outside this range will be denied access.
• At the profile level, you can set login hours for every day of the week.
• If you want to remove user access for the whole day like on Saturday and Sunday just set the login hours from 12 AM to 12 AM.

Difference Between Company-Level Restriction and Profile-Level Restriction

1. Individuals who are not within the company's IP range will receive an activation code which they can use to log in to the system. Once the code is entered, they can access their account.
2. Individuals who are not within the designated IP Range for their profile level will not receive any codes and will be denied access.
3. To ensure that users can log in at any time, keep the login hours unchanged for their profile, allowing access 24/7.

2-Object Access

Profile

Profiles determine the objects users can access, and the permission they have on an object record. Profiles control which tabs are visible in the app Launcher. They also determine object access and what permission people have to each object: Create, Read, Edit, and Delete.

Object Level

CRED access for the object we can control at the profile level.
For example, there are two profiles, one is Sales User and one is the Marketing User. So for the Marketing user profile, we will give only read edit and create access for the opportunity record, marketing user will not have delete access for the opportunity record, because we want to give all opportunities to our sales User to evaluate wins and losses of opportunities, and then Sales Users can delete opportunities as we are giving them full CRED access for Opportunity.

Field Level

Field-level security allows us to grant and restrict visibility to individual fields based on a user’s profile.

Let’s take the example of our Sales Profile And Marketing Profile.
There is a field on the Account object , we don’t want our marketing users to see how much profit we are making in a transaction, so we will remove read access of the Profit field from the Marketing profile. We can control both read and edit access of fields at the profile level.

3-Record Access

Organization-Wide Default Settings:

Organization-Wide Default Settings determine what access and permissions users have to records they don’t own.

There are four options for giving access to others’ records.

1-Public Read/Write/Transfer: Allows non-owners to view, edit and change ownership, this public ability to transfer ownership only applies to Lead and Cases. For other standard objects, only the owner or somebody above them in the role hierarchy can transfer the ownership.

2-Public Read/Write: Allows non-owners to view, and edit the record.

3-Public Read Only: Allows non-owners to only view the records.

4-Private: Most Restricted Setting is private here users can not even see records they do not own.

Profile permission determines the baseline level of access a user has to all records, org-wide default can then further restrict this permission on records a user does not own.

Org-wide can never grant a user more access than they have through the object permission.

For Example: If a user’s profile doesn’t have read access to Account Object, then you can not give him Account records read access with OWD.

Roles And Roles Hierarchy

The role hierarchy is a way to extend access to records when org-wide sharing settings have been set to anything more restrictive than Public Read/Write.

OWD for the Opportunity record is private, only owners can see their opportunity records. Sales Representatives are working on opportunities and have access to their records only. But the sales manager wants to see all the opportunity records on which his team members are working. This will happen with the help of role hierarchy.

We will create a role hierarchy where all the sales representatives will be under the sales manager.
We can edit roles and control access levels if we want to give only view access or view and edit both access to the people sitting on the upper level of the role hierarchy.

Note: If you want to add a role to a user, go to setup>user>select user and edit and then select a role for the user. The role is optional for a user.

Sharing Rules

The sharing rules open record access to the users when org-wide sharing settings have been set to anything more restrictive than Public Read/Write.

We can create two types of sharing rules.

a-Owner-Based: We can share a record owned by a user with other users. We can share records based on public groups, roles, or role subordinates.
Example: We want to share all the records of users having sales rep roles with the users having sales executive roles.

b-Criteria-Based: We can share records based on certain criteria.
Example: We want to share all won opportunities with the finance team. Here we will create a sharing rule on an opportunity where we will set a criteria stage name equal to WON.

Manual Sharing

Record owners can share records by clicking the share button on the record detail page.

Permission Sets

Permission sets allow users to have extended access and additional permissions.

Profiles give access to objects, tabs, fields, and many other functions. Every user is assigned one profile. Typically, a profile provides access to the general function, that a type of user performs.
But what if some users need access to additional objects and settings, and you don’t want to grant that access to everyone with the profile?

A permission set is above and beyond the profile, so you can only give access to the user who needs it.

Permission Sets hold many of the settings found in the profile, like object and field permission.
Users can have only one profile, and they can have many permission sets, so you can grant additional access without changing the profile.

Thanks for reading please let me know your thoughts in the comment section.
#sfdc #crm #crmplateform #crmsoftware #srmsolution #salesforce #salesforce software #salesforce platform #salesforce marketing
#salesforce developers