Object Level Security in Salesforce

Salesforce stores vast amounts of client data, raising security concerns. To prevent threats, it provides various security settings. It allows you to control access at different levels. One such level is the Object Level Security in Salesforce.

The necessary security measures are made more robust with these settings. So, let’s understand what Object Level Security is and how you can implement it in your Salesforce org.

What is Object Level Security in Salesforce?

Providing you with the simplest way to control data access, Salesforce Object Level Security is the go-to feature for you. It prevents a user or group of users from creating, viewing, editing, or deleting any records of an object by setting permissions on that object.

Object permissions either respect or override sharing rules and settings. The following permissions specify the access that users have to objects.

How Does Object Level Security Work in Salesforce?

There are two primary ways of setting object permissions Salesforce:

1. Profiles

Every Salesforce user is assigned a profile. It defines a user’s role in the organization and controls what the user can do with the records they can access. It determines the objects a user can access and the permissions a user has on any object record.

2. Permission Sets

It provides users with additional permissions and access settings. In Permission Sets, we can only give different permissions to users. Still, we can’t restrict permissions already granted to users at the profile level; they can only be assigned to users, not to profiles.

Note: With new updates, Salesforce has announced that all user permissions will be managed using permission sets and permission set groups, with profiles becoming simpler.  

What are Profiles In Salesforce

A profile is a collection of settings and permissions that determine which data and features users can access on the platform. It is like a template: whenever we want to create a new profile, we have to choose one from the profiles Salesforce already provides, and then we can customize it according to our requirements.

To avoid having to set all permissions and settings from scratch, you must choose an existing profile when creating a new profile. Profile settings determine what users can see, such as apps, tabs, fields, and record types. Whereas Permission determines what users can do, for example, create or edit records of a particular kind, run reports, and customize the app. 

Here is what the Profiles can control.

• Object Permission
• Field Permission
• User Permission
• Tab Settings
• App Settings
• Apex class access
• Visualforce page access
• Page Layouts
• Record Types
• Login Hours
• Login IP Ranges

A user’s job function typically defines profiles. Still, anything that makes sense in an organization can be created as a profile. There is a set of standard profiles in Salesforce.

Each standard profile includes a default set of permissions for all standard objects available on the platform. Here is what each profile type entails in Salesforce.

1. Standard User: The standard User profile in Salesforce has Read, Edit, and Delete permissions to most standard objects. Delete access is usually restricted by default. 
2. Read Only: Read-only users have read access to most standard objects. Unlike standard users, they cannot create/edit/delete.
3. Marketing User: Permissions of Standard User + Additional Permissions.
4. Contract Manager: Permissions of Standard User + Additional Permissions.
5. Solution Manager: Permissions of Standard User + Additional Permissions.
6. System Administrator: The System Administrator profile has the most comprehensive access to data and the greatest ability to configure and customize Salesforce. The System Administrator profile also includes two special permissions: “View All Data” and “Modify All Data.”

Key Points to Note

1. Object permissions on the Standard profile cannot be edited. To overcome this, creating a new profile by copying/cloning standard profiles and then customizing the copies to fit the organization’s needs is a good approach. Profile functionality within an organization depends on the user’s license type.
2. Every profile should have at least one visible app.
3. Even when an app is set to visible in profile settings, its tab will only appear if a profile has Permission to view the associated objects for that tab.
4. A profile can be assigned to many users, but the user can be set to only one profile at a time.
5. When a custom object is created, most profiles, except those with modify all data permission, do not give access to that custom object.