Andy Tran

Salesforce Data Security Model

by | 13 Jun, 2023 | Salesforce | 0 comments

Salesforce data security model

Salesforce provides a flexible data security model to secure data at different levels.

Salesforce also provides sharing tools to open up and allow secure access to data based on business needs.

Exploring the Robust Salesforce Data Security Model

Salesforce uses 3 levels of security:
1. Object – Level Security –To secure Access to—–> Objects.
2. Field – Level Security –To Secure Access to—> Fields.
3. Record – Level Security —To secure Access to—> Individual Records.

You need to know what are objects, fields, and records, as well as what is role hierarchy is in an organisation.

Let’s see what is Objects, Fields and Records in Salesforce.

objects, field sand record in Salesforce

Let’s see what Role Hierarchy Looks in Organization.
It is a basic example How it looks and remember that the below guy’s report to higher guys in this flow.

Role Hierarchy Looks in Organization

Assume that the Sales Executive is “PersonABC” & Service Executive is “PersonXYZ”.

Assume that the Sales Executive is “PersonABC” & Service Executive is “PersonXYZ”.

“PersonABC” recently joined “EruditeWorks” as a “Sales Executive”.
He is also having a marketing group and he is under “CEO” and also,
He has two employees below, those guys are reporting to “PersonABC”.
He need access on some various Objects and Apps in Salesforce

Before allowing a user access, Salesforce first verifies that the user has permission to see the Objects?
If not, we can give access by using

    • Profiles
    • Permission Sets
    • Permission Set Groups

Even if “PersonABC” has access to Objects, he still needs access to individual “fields” on each object.
If not, we achieve this by using

    • Profiles
    • Permission Sets

Yes, Profiles and Permission sets also control field level Security.

We recommended to use field level security instead of just removing a field from a Record Page or Page Layout

With just Object Level & Field Level access.
Our PersonABC can only access Records he Owned.
But if He needs PersonXYZ Records…? Then he needs to know about the “Sharing”.

This is where Salesforce introduces the
“Salesforce Sharing Model” or “Record Sharing” or “Sharing”

example for salesforce data security model
salesforce sharing model

Record Level Security


OWD stands for Organization Wide Default (OWD).
Organization Wide Default settings are baseline settings in Salesforce specify which records can be accessed by which user and in which mode.

Some Types of OWD:
2. Public read only,
3. Public read/write,
4. Public Read/Write/Transfer (only available of Leads and Cases)


    • The Owner of the records has full ”CRUD “access on Owned Records.
    • And here salesforce also provided other ways to automatically assign ownership to users on records and transfer ownership from one user to another user.
    • Ownership can also be granted to a group of users Like, “QUEUE” etc.,

For Example,
On Account object – PersonABC & PersonXYZ creates some Records.

  • IF OWD is private & Does PersonABC get PersonXYZ records ?
    • No, here it means they have full access to their own records.
  • If OWD is Public Read Only
    • Here for their own records have full access and others records have read access only
  • If OWD is Public Read/Write Only
    • Here for their own records have full access and others records have read/write access only
  • Can we change the child OWD setting if the Parent and child have Master-Detail Relationship?
    • No, the Child record is controlled by the Parents setting.

Role Hierarchy
Typically, in an organisation, different Jobs roles have different record access requirements.

    • Normally Job roles are sorted in a hierarchical way: –
      • Higher role guys access the below guy’s records.
      • Whereas below guys cannot access above guys owned records.

In our case, Our PersonABC can access the lower Sales Persons records, But PersonABC has no permission to access the CEO Owned records.

Sharing Rules
See in above sharing model, sharing a record is possible in Upward and in Vertical direction only.
Do we want to share the records which are owned by PersonABC with PersonXYZ?

Sharing rules provide a way to share records via public groups.
This can be done in 3 Ways:

    1. Owner Based Sharing Rules
    2. Criteria Based Sharing Rules
    3. Guest user Based Sharing Rules

Manual Sharing
Manual sharing provides a mechanism to share individual records with others. These permissions are accessed through the “sharing button “on the record details page.

This is only available if OWD is Private or Public read only because in public reading/writing everyone sees every one’s record.

Apex Sharing
There are some cases when you can’t share records via UI or settings, but you need to write Apex Code for it.


Salesforce offers three layers of security and plenty of customization to meet almost any company demand. Profiles and permission settings govern object and field access, with permission sets being our preferred tool. Instead of using profiles, permission set groups are the next generation way to model job roles.

Furthermore, record-level security is divided into five categories: org-wide defaults, role hierarchy sharing, sharing rules, manual sharing, and Apex-based sharing. These five controls who has access to a set of records or even an individual record.

Also Read: Einstein Vision and Language Model Builder

Looking to enhance your business processes and leverage Salesforce’s full potential? Look no further. As a trusted Salesforce consulting partner, we specialize in tailored solutions for businesses of all sizes. Our certified experts will work closely with you to streamline operations, maximize ROI, and ensure a seamless transition and successful adoption. From implementing and customizing Salesforce CRM to optimizing automation and integrating third-party systems, we’ve got you covered.

Share this article...


Submit a Comment

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.