Data security in Salesforce refers to the comprehensive set of practices, configurations, and technologies used to protect sensitive information stored within a Salesforce org. It defines what data a user can see, what records they can access, and what operations they can perform — all the way down to individual fields on a record.
Salesforce provides a flexible, layered security model that allows organizations to assign different data access levels to different sets of users. What makes this model particularly powerful is that it is configured through the user interface but enforced at the API level — meaning permissions apply whether a user accesses data through the Salesforce UI or through an API call.
In simple terms, Salesforce data security answers two fundamental questions:
- Who can log into your Salesforce org?
- What can they see and do once they’re inside?
Why Data Security in Salesforce Matters?
As cyberattacks continue to rise across industries, protecting customer data, employee records, and financial information inside your CRM has become a top priority. A misconfigured Salesforce org can expose sensitive personally identifiable information (PII), violate compliance regulations like GDPR, and create costly security breaches.
Here’s why every Salesforce Admin must treat data security as a core responsibility:
- Compliance and regulation: Industries such as healthcare and finance operate under strict regulatory frameworks (HIPAA, GDPR, etc.) that dictate how personal data must be stored and accessed.
- Data integrity: Improper access can lead to accidental or malicious data modifications that damage business operations.
- Reputation and trust: A data breach can irreparably damage your organization’s reputation with customers and partners.
- Shared responsibility: Salesforce secures the infrastructure, but it is the organization’s responsibility to properly configure the security and sharing model within their org — this is known as the Shared Responsibility Model.
Think of it this way: Salesforce builds you a secure house with locks and an alarm system. But you are responsible for locking the doors, keeping the key safe, and actually using the alarm.
The 4 Levels of Data Security in Salesforce
Data security in Salesforce is organized into four distinct levels, each building on the previous one to create a comprehensive, layered defense for your data:
| Level | Controls |
|---|---|
| 1. Organization | Who can log in, password policies, IP restrictions, login hours |
| 2. Object | Which objects (e.g., Accounts, Leads) a user can view, create, edit, or delete |
| 3. Field | Which fields within an object a user can read or write |
| 4. Record | Which individual records a user can access within an object |
Let’s break down each level in detail.
Level 1 – Organization-Level Security
Organization-level security is your first line of defense. It controls who can access your Salesforce environment at all.
Key tools at this level include:
User Management:
Only verified, credentialed users should be provisioned with the appropriate Salesforce license. Deactivating users promptly when they leave your organization is a critical hygiene task.
Multi-Factor Authentication (MFA):
MFA requires users to verify their identity using a second factor (such as an authenticator app) in addition to their password. Salesforce has made MFA mandatory for all users, and it is one of the most effective protections against unauthorized access.
Login IP Restrictions:
Admins can restrict login access to specific IP address ranges, ensuring that users can only access Salesforce from approved networks (e.g., corporate offices or VPNs).
Login Hours:
You can restrict when users are allowed to log in. For example, you might only allow your sales team to access Salesforce during business hours (9 AM–6 PM, Monday–Friday).
Password Policies:
Setting strong password requirements — including minimum length, complexity, expiration intervals, and lockout policies — reduces the risk of brute-force attacks.
Pro Tip: Following the Principle of Least Privilege (PoLP), each user should only have the minimum access needed to do their job — nothing more, nothing less.
Level 2 – Object-Level Security
Once a user is inside your org, object level security determines which Salesforce objects (think: database tables) they can interact with — and what they can do.
The access types available at object level are:
- Read – View records
- Create – Add new records
- Edit – Modify existing records
- Delete – Remove records
- View All – See all records regardless of ownership
- Modify All – Edit and delete all records regardless of ownership
Profiles
Every Salesforce user must be assigned exactly one Profile. Profiles define the baseline settings for users including login access, page layout assignments, and object permissions. Best practice today is to set profiles to minimum access and use Permission Sets to add permissions on top.
Permission Sets & Permission Set Groups
Permission Sets are the modern, recommended way to grant object and field permissions. Unlike profiles, you can assign multiple permission sets to a single user, making them far more flexible and granular.
For example, instead of one large “Sales Executive” profile, you can create smaller permission sets like “Manage Leads,” “Approve Opportunities,” and “View Forecasts” — and assign only what each user actually needs.
Permission Set Groups allow you to bundle multiple permission sets together, so assigning a group of permissions to a user can be done in a single action.
Level 3 – Field-Level Security
Even if a user has access to an object, you may not want them to see every field on a record. Field Level Security (FLS) lets you control exactly which fields a user can see or edit.
Field-level access options are:
- Visible + Editable – User can read and update the field
- Visible + Read-Only – User can see the field but not change it
- Hidden – The field is completely invisible to the user (even via API)
Common Field-Level Security Use Cases
- Hiding the Salary field on a Position record from interviewers but making it visible to HR managers
- Making a Credit Card Number field read-only for customer service reps
- Hiding Social Security Number from all users except compliance officers
Best Practice: Always use Field-Level Security to restrict sensitive data rather than simply removing a field from a page layout. A field removed from a page layout can still be accessed via API or reports — FLS applies universally.
Level 4 – Record-Level Security
Object-level and field-level security control what kind of data a user can access. Record-level security controls which specific records they can access within a given object.
By default, when a user creates a record in Salesforce, they become the record owner and have full access to it. But your business needs are rarely that simple. Record-level security — also known as the Salesforce Sharing Model — provides the tools to manage this.
The Salesforce Sharing Model Explained
The Salesforce sharing model is implemented through five key mechanisms. The recommended approach is to start with the most restrictive settings and then open up access as needed.
1. Organization-Wide Defaults (OWD)
OWD settings define the baseline access to records for users who do not own them. This is always your starting point.
The three main OWD settings are:
- Private – Users can only access records they own
- Public Read Only – All users can view records, but only owners can edit them
- Public Read/Write – All users can view and edit records
The golden rule: set OWD to the most restrictive level your business allows, then use the tools below to open access where needed.
2. Role Hierarchy
Role Hierarchy represents your organization’s reporting structure in Salesforce. Users in a higher role automatically inherit read access to records owned by users in roles below them.
For example, a Regional Sales Manager would automatically be able to see records created by their Sales Representatives.
Note: A role hierarchy is not the same as an org chart. It specifically maps data access relationships, not reporting lines.
3. Sharing Rules
Sharing Rules extend record access to specific groups of users without going through the role hierarchy. There are two types:
Ownership-Based Sharing Rules: Share records based on who owns them. For example, share all records owned by users in the “Sales Executive” role with users in the “Sales Support” role.
Criteria-Based Sharing Rules: Share records based on the values of specific fields, regardless of ownership. For example, share all Account records with a Billing City of “New York” with the East Coast Sales team.
4. Manual Sharing
Manual sharing allows end users to individually share a specific record with another user or group directly from the record detail page. This is available when OWD is set to Private or Public Read Only.
This is useful for one-off, ad-hoc sharing needs that can’t be automated through rules.
5. Apex Managed Sharing
For complex sharing scenarios that can’t be achieved through the UI, Salesforce developers can write Apex code to programmatically control record sharing. This is the most flexible — and most complex — option.
Salesforce Data Security Best Practices
Mastering data security in Salesforce is not just about knowing the tools — it’s about applying them consistently and strategically.
1. Apply the Principle of Least Privilege (PoLP) Only grant users the access they absolutely need to do their job. Ask yourself: “Can this user still do their job with fewer permissions?” If yes, reduce access.
2. Set OWD to Private First Always start with the most restrictive OWD setting and use sharing rules and role hierarchy to open access incrementally. It’s much harder to restrict access after the fact than to open it up carefully.
3. Classify Your Data Understand what types of data you store (PII, sensitive personal data, financial data) and build your security model accordingly. Data classification drives encryption, access controls, and retention policies.
4. Use Permission Sets Over Profiles Salesforce officially recommends permission sets as the primary vehicle for managing object and field permissions. Keep profiles at minimum access and layer permissions on top with permission sets and permission set groups.
5. Enable and Enforce MFA Multi-Factor Authentication is now required by Salesforce. Ensure it is enabled and actively enforced for all users, especially admins.
6. Document Your Security Model Maintain a clear, up-to-date document that maps user roles to their level of access. This is essential for audits, compliance reviews, and onboarding new admins.
7. Monitor Your Org Regularly Use Salesforce’s built-in monitoring tools to stay on top of security:
- Health Check – Identifies and prioritizes security risks in your org
- Setup Audit Trail – Tracks metadata changes
- Event Monitoring – Logs high-risk user activities
- Field History Tracking – Records changes to specific field values
8. Follow the Shared Responsibility Model Salesforce secures the platform infrastructure. Your organization is responsible for securing everything above the platform layer — user access, sharing settings, data management, and compliance.
Key Tools for Salesforce Data Security
Beyond the core security and sharing model, Salesforce offers a suite of advanced products to support data protection at scale:
| Tool | Purpose |
|---|---|
| Salesforce Shield | Platform Encryption, Event Monitoring, and Field Audit Trail for highly regulated orgs |
| Security Center | A unified dashboard to view, analyze, and manage security across your org and connected orgs |
| Privacy Center | Manage constituent consent and data subject rights to support GDPR compliance |
| Data Mask & Seed | Mask sensitive data in sandboxes to prevent exposure during development and testing |
| Backup & Recover | Automated data backup with notifications for data loss or corruption |
| Health Check | Measures your org’s security settings against Salesforce’s recommended baseline |
FAQs About Data Security in Salesforce {#faqs}
Q: What are the 4 levels of data security in Salesforce?
A: The four levels are Organization Level, Object-Level, Field-Level, and Record-Level security. Each layer provides finer control, with organization-level being the broadest and record-level being the most granular.
Q: What is the Salesforce sharing model?
A: The Salesforce sharing model (record-level security) includes five mechanisms: Organization-Wide Defaults (OWD), Role Hierarchy, Sharing Rules, Manual Sharing, and Apex Managed Sharing.
Q: What is OWD in Salesforce?
A: Organization-Wide Defaults (OWD) define the baseline record access for users who do not own a record. Settings include Private, Public Read Only, and Public Read/Write. Best practice is to start with Private and grant additional access using sharing rules.
Q: What is the difference between a Profile and a Permission Set?
A: A Profile is required for every user and sets baseline access. Permission Sets are optional but recommended for managing object and field permissions. Each user can have one profile but multiple permission sets — making permission sets far more flexible.
Q: What is Field-Level Security in Salesforce?
A: Field-Level Security (FLS) controls which fields a user can see or edit on a record. Unlike removing a field from a page layout, FLS is enforced at the API level, meaning the restriction applies even through API calls and reports.
Q: What is the Principle of Least Privilege in Salesforce?
A: The Principle of Least Privilege (PoLP) means granting users only the minimum access required to perform their job function. It is a core data security methodology that reduces the risk of both accidental and malicious data exposure.
Q: Is Salesforce data security covered in the Admin certification exam?
A: Yes — data security and access control is one of the most heavily weighted topics in the Salesforce Certified Administrator exam, covering profiles, permission sets, OWD, role hierarchy, and sharing rules.
Ready to Master Salesforce Admin?
Take Your Salesforce Skills to the Next Level
Understanding data security in Salesforce is just one piece of the puzzle. To truly master the platform — and land a Salesforce Admin certification — you need structured, hands-on training that covers every exam topic from A to Z.
That’s exactly what our Salesforce Admin Certification Course is designed to deliver.
Final Thoughts
Data security in Salesforce is not a one-time setup task it’s an ongoing practice. By understanding the four levels of data access, applying the Principle of Least Privilege, building a well-documented sharing model, and continuously monitoring your org, you can ensure that your Salesforce environment remains secure, compliant, and trustworthy.
The more deeply you understand Salesforce’s security architecture, the more valuable you become as an admin and the better positioned you are to pass the Salesforce Admin certification exam.
