Introduction

Who doesn’t want their org data to be safe and secure? And I’m sure it doesn’t end there. Don’t we want the data to be accessed only by those who are meant to access them?

That’s where Salesforce’s flexible, layered sharing model comes into play. Let’s look at how this model works:

• We can easily grant access to different data sets to different sets of users.
• The platform simplifies the task of specifying whether a User can view, edit, create, or delete specific fields or even individual records in the org.
• We can manage access to the entire org, a particular object, a specific field, or even an individual record with the help of the layered sharing model.
• The security and sharing configurations performed using the UI interface reflects in the API level.

Levels of Data Access

The layered sharing model enables us to control User access to the entire org, a particular object, a certain field, or a specific record. Let’s look at how it works.

1. Organization

There are specific security measures that we can put up for our entire org, such as:

• Set password policies
• Limit login to certain hours and locations
• Manage Users
• Specify Trusted IP ranges for the org

2. Objects

Object-level security presents the easiest way to manage which Users have access to which data. We can control whether a category of users can create, view, edit, read, or delete records of an object. Each category of Users shares a profile that determines the User’s access to the org.

Each User is assigned a particular profile. Depending on the profile, the User can access data and perform specific actions on it. We have the option to grant additional access using permission sets.

3. Fields

The next level of restriction is performed at the field level after setting up the object-level conditions.

Although a User may have access to a record, we may want to restrict access to fields within the record. This can be performed with the help of field-level restrictions. We can limit field access with Profiles and open access with permission sets.

4. Records

Sometimes, a User can access only certain Records with an Object. This is possible due to record-level security. We use record-level security to control data access with greater precision.

Audit System Use

Auditing offers vital information for identifying potential or real security threats. It’s best practice to have someone in your org to keep a check on the org by regularly auditing to find discrepancies. Look for anything out of place.

Record Modification Fields

All Objects include fields that contain the name of the User that created the field and the name of the User that last modified it. This can provide the elementary information required to audit an org.

• Login History
  The login history page lets us view up to 20,000 records of user logins for the past six months.
• Field Tracking
  Field-level auditing exists for all custom objects and a few standard objects. We can turn on tracking for specific fields and display the history in the History Related List of an object.

• Setup Audit Trail
  This functionality lets us track any setup changes made by you or any other admin in your org.