Salesforce Data Security Model: Object, Field, and Record-Level Security

Introduction

Salesforce implements a multi-layered data security model that enables administrators to control access at different levels, ensuring data integrity, compliance, and privacy. Understanding these levels is essential for Salesforce Admins, Developers, and Architects to manage secure and structured access to data.

This guide explains Object-Level, Field-Level, and Record-Level Security in Salesforce with step-by-step configurations and best practices.

1. Object-Level Security (CRUD Permissions)

Object-level security controls access to entire objects (e.g., Accounts, Contacts, Opportunities). Users can be restricted from creating, reading, editing, or deleting records of a particular object.

🔹 How to Configure Object-Level Security?

✅ Managed via: Profiles & Permission Sets

✅ Steps to Set Object Permissions in Profiles:

Navigate to Setup → Profiles.
Select the profile you want to modify (e.g., "Sales User").
Under Object Settings, choose the object (e.g., Opportunity).
Set permissions: Create, Read, Edit, Delete (CRED).
Click Save.

✅ Steps to Set Object Permissions Using Permission Sets:

Go to Setup → Permission Sets.
Select the Permission Set or create a new one.
Click Object Settings, choose an object, and modify its permissions.
Assign the Permission Set to users.

✔ Object-Level Security Permissions:

Create → Allows record creation.
Read → Grants read-only access.
Edit → Enables modifications.
Delete → Allows deletion of records.
View All / Modify All → Overrides sharing settings and grants full access.

📌 Use Case: A Sales Rep can view and edit Opportunities but not delete them.

2. Field-Level Security (FLS)

Field-level security controls visibility and editability of specific fields within an object. Users may have access to an object but can be restricted from viewing or editing certain fields.

🔹 How to Configure Field-Level Security?

✅ Managed via: Profiles & Permission Sets

✅ Steps to Set Field-Level Security in Profiles:

Navigate to Setup → Profiles.
Select the Profile you want to edit.
Scroll to Field-Level Security and click the object name.
Modify access to fields (Visible / Read-Only / Hidden).
Click Save.

✅ Steps to Set Field-Level Security Using Permission Sets:

Go to Setup → Permission Sets.
Select the Permission Set.
Click Field Permissions, select an object, and modify field access.
Assign the Permission Set to users.

✔ Field-Level Security Options:

Read-Only → Users can see but not edit the field.
Hidden → Users cannot see the field at all.

📌 Use Case: A Finance User can view an employee's salary, but a Sales User cannot.

3. Record-Level Security (Sharing & Ownership)

Record-level security controls who can access specific records within an object. Even if users have object and field access, they may not be able to see individual records unless allowed by record-level security settings.

🔹 How to Configure Record-Level Security?

✅ Managed via:

Organization-Wide Defaults (OWD) → Sets baseline access.
Role Hierarchy → Allows managers to see subordinates’ records.
Sharing Rules → Grants additional access based on criteria.
Manual Sharing → Users manually share specific records.
Teams & Territories → Enhances collaboration with defined access.

✔ Key Record-Level Security Features:

🔹 3.1 Organization-Wide Defaults (OWD)

Go to Setup → Sharing Settings.
Modify OWD settings for each object.
Available options:
- Private → Users can only access their own records.
- Public Read Only → Users can view but not edit others' records.
- Public Read/Write → Users can view and modify all records.
- Public Read/Write/Transfer → (Only for Leads & Cases).

📌 Use Case: A Sales Rep can see only their own Accounts, while a Sales Manager can view all reps' Accounts.

🔹 3.2 Role Hierarchy

Navigate to Setup → Roles.
Define role structure (e.g., VP → Manager → Sales Rep).
Assign users to appropriate roles.

📌 Use Case: Managers can access subordinate records, but not vice versa.

🔹 3.3 Sharing Rules

Go to Setup → Sharing Settings.
Define criteria-based record sharing for roles/groups.
Choose Read-Only or Read/Write access.

📌 Use Case: Automatically share Opportunities with Marketing Team if deal size > $50,000.

🔹 3.4 Manual Sharing

Available when OWD is set to Private.
Record owners can manually share records with specific users.

📌 Use Case: A Sales Rep shares a key Account with a colleague for collaboration.

🔹 3.5 Restriction Rules (Enterprise & Unlimited Editions)

Further limits visibility of records based on criteria.

📌 Use Case: Restrict users from viewing Cases outside their region.

4. Security Layer Hierarchy in Salesforce

Salesforce follows a structured security access order:

📍 Object-Level → Field-Level → Record-Level Security

✔ Profiles & Permission Sets → Define what users can do.
✔ OWD → Sets the base level of record access.
✔ Role Hierarchy → Expands access for managers.
✔ Sharing Rules & Manual Sharing → Provide additional access when needed.
✔ Restriction Rules → Further filter data visibility.

💡 Best Practice: Follow the Principle of Least Privilege – Grant only the necessary access to users.

5. Summary: Choosing the Right Security Approach

✔ For structured access (Manager-Subordinate): Use Roles.
✔ For ad-hoc sharing: Use Manual Sharing.
✔ For sharing across teams: Use Sharing Rules.
✔ For field-based restrictions: Use Field-Level Security.
✔ For granular control over record visibility: Use Restriction Rules.

📌 Implementing the right security model ensures data integrity, compliance, and optimal performance!

6. Final Thoughts

Understanding Salesforce’s security model is essential for protecting data, ensuring compliance, and maintaining efficient access control. A combination of OWD, Profiles, Role Hierarchy, Sharing Rules, and Manual Sharing provides granular control over record visibility.

Which security feature do you configure most often? Let’s discuss! 🚀

Search This Blog