Security in Salesforce isn’t a single switch you flip on or off. It’s a layered system where each layer controls a different aspect of data access. Understanding these layers is essential whether you’re an admin setting up permissions, a developer writing code, or an architect designing solutions.

This article breaks down Salesforce’s security model into its core components, explains how each layer works, and shows how they interact to control who sees what data.

The Four Layers of Data Security

Salesforce security operates at four distinct levels, each controlling access at different granularity:

1. Organization-level security - Who can log in to your Salesforce org
2. Object-level security - Which objects (tables) users can access
3. Field-level security - Which fields within objects users can see or edit
4. Record-level security - Which specific records users can access

These layers work together. A user must pass each level to access data. If any layer blocks access, the user can’t see that data, even if other layers permit it.

Layer 1: Organization-Level Security

This layer controls who can log into your Salesforce org in the first place. It includes:

User Authentication

The basic requirement: valid username and password. Salesforce enforces password policies including minimum length, complexity requirements, expiration periods, and lockout policies after failed login attempts.

Multi-Factor Authentication (MFA)

As of February 2022, Salesforce requires MFA for all users accessing Salesforce products via the UI. Users must verify their identity using a second factor beyond their password—typically a mobile authenticator app, security key, or built-in authenticator.

IP Restrictions

You can restrict login access to specific IP address ranges. Users attempting to log in from outside these ranges are blocked, even with correct credentials. This is commonly used to restrict access to office networks or VPN connections.

Login Hours

Profiles can specify when users are allowed to log in. Outside permitted hours, users are automatically logged out and cannot log back in until the permitted window starts.

These controls determine who gets through the front door. Once authenticated, object-level security takes over.

Layer 2: Object-Level Security

Object-level security controls which objects (like Account, Contact, or custom objects) users can access. This is managed through profiles and permission sets.

Profiles

Every user has exactly one profile. Profiles define baseline permissions including which objects the user can Create, Read, Edit, and Delete (CRUD). These permissions apply to the object as a whole.

For example, a Sales User profile might grant:

• Read and Edit on Accounts
• Read, Create, Edit on Contacts
• No access to custom HR objects

Permission Sets

Permission sets extend profile permissions. They grant additional access but cannot remove permissions already granted by the profile. Users can have multiple permission sets assigned.

This design allows you to maintain a small number of profiles for broad user categories while using permission sets to grant specific additional permissions as needed.

View All and Modify All

Profiles and permission sets can grant "View All" or "Modify All" permissions on specific objects. These powerful permissions bypass record-level security (sharing rules) for those objects, granting access to all records regardless of ownership or sharing settings.

If object-level security grants access, field-level security applies next.

Layer 3: Field-Level Security (FLS)

Object access doesn’t automatically mean access to all fields within that object. Field-level security controls which fields users can view or edit on objects they can access.

How FLS Works

For each field on each object, you specify whether users with a given profile or permission set can:

• View the field (read access)
• Edit the field (write access)
• Have no access to the field

Fields marked as not accessible are hidden from the user interface. More importantly, they’re also inaccessible via API calls, reports, and SOQL queries unless specifically overridden in code.

Common Use Cases

FLS is commonly used for:

• Hiding sensitive fields (salary information, social security numbers)
• Preventing users from editing system-calculated fields
• Restricting access to fields used only by specific departments
• Controlling visibility of pricing or cost information

FLS in Code

Apex code runs in system context by default, bypassing FLS. Developers must explicitly enforce FLS in their code using:

• WITH SECURITY_ENFORCED clause in SOQL queries
• Security class methods like Schema.sObjectType.Account.fields.Revenue.isAccessible()
• Lightning Web Components that automatically enforce FLS when using Lightning Data Service

This is a common security gap: object-level permissions are checked, but FLS is forgotten in custom code.

Layer 4: Record-Level Security

Object and field permissions control what types of data users can access. Record-level security controls which specific records they can access.

Organization-Wide Defaults (OWD)

OWD sets the baseline record access level for each object. The most common settings are:

Private: Users can only see records they own or that are explicitly shared with them. This is the most restrictive setting.

Public Read Only: Users can view all records but can only edit records they own or that are explicitly shared with them.

Public Read/Write: Users can view and edit all records.

Controlled by Parent: For child objects in master-detail relationships, access is determined by the parent record’s sharing settings.

Role Hierarchy

Salesforce’s role hierarchy grants access based on organizational structure. Users higher in the hierarchy can access records owned by users below them, even if OWD is set to Private.

For example, a Sales Manager can see opportunities owned by their sales reps, even though those reps can’t see each other’s opportunities.

This access flows upward through the hierarchy automatically. If you don’t want this behavior, you can disable "Grant Access Using Hierarchies" for specific objects.

Sharing Rules

Sharing rules extend access beyond ownership and role hierarchy. They grant access to records based on criteria:

Ownership-based sharing rules: Share records owned by users in one group with users in another group.

Criteria-based sharing rules: Share records matching specific criteria with specific users or groups.

For example, a rule might share all Accounts in the "Technology" industry with the Technology sales team, regardless of who owns those accounts.

Manual Sharing

Record owners and users with "Full Access" to a record can manually share individual records with other users, roles, or groups. This is useful for one-off exceptions but doesn’t scale for systematic access patterns.

Apex Sharing

Developers can programmatically create sharing rules using Apex code. This enables complex sharing logic based on business requirements that standard sharing rules can’t express.

How the Layers Work Together

A user trying to access a field on a record must pass all four layers:

1. Can they log in? (Organization-level security)
2. Can they access this object? (Object-level security via profile/permission sets)
3. Can they see this field? (Field-level security)
4. Can they access this specific record? (Record-level security via OWD, hierarchy, sharing rules)

If any layer denies access, the user cannot access that data. All layers must grant access for the user to see or modify the data.

Example Scenario

Sarah is a sales rep trying to view the Annual Revenue field on an Account record:

• Organization-level: Sarah has valid credentials and is logging in during permitted hours from an allowed IP address. ✓
• Object-level: Sarah’s profile grants Read access to Accounts. ✓
• Field-level: The Annual Revenue field is set to "Not Visible" for Sarah’s profile. ✗

Sarah cannot see the Annual Revenue field, even though she can access the Account record. The field simply doesn’t appear in her view.

Common Security Mistakes

Mistake 1: Granting "Modify All Data" Permission

This permission bypasses all security layers. Users with this permission can access, modify, and delete any data in the org. It should be granted sparingly, typically only to system administrators.

Mistake 2: Ignoring FLS in Code

Apex code bypasses field-level security by default. Developers must explicitly check FLS when writing custom code, or users might access fields through custom functionality that they can’t access through standard UI.

Mistake 3: Overly Permissive OWD

Setting organization-wide defaults to Public Read/Write reduces your control over record access. Start with Private and use sharing rules to grant access as needed. It’s easier to open access than to restrict it after data is already accessible.

Mistake 4: Confusing Profiles and Permission Sets

Profiles define baseline permissions; permission sets extend them. If you find yourself creating many nearly-identical profiles, you probably need a few base profiles with targeted permission sets instead.

Mistake 5: Not Testing with Actual User Permissions

Security looks different from an admin account than from a regular user account. Always test security configurations by logging in as users with the actual permissions you’ve configured.

Security in Development

When developing on Salesforce, security considerations affect every layer of your code:

SOQL Queries

By default, SOQL queries return records the running user can access based on sharing rules. However, they don’t enforce field-level security. Use WITH SECURITY_ENFORCED to make queries respect FLS:

List<Account> accounts = [
SELECT Id, Name, Industry
FROM Account
WITH SECURITY_ENFORCED
];

If a user lacks access to any queried field, the query fails. This prevents partial data exposure.

Apex Class Sharing Keywords

Apex classes can run in three modes:

with sharing: Enforces the running user’s sharing rules without sharing: Ignores sharing rules, giving access to all records inherited sharing: Inherits the sharing mode from the calling context

Default is "without sharing" for historical reasons, which is often not what you want. Be explicit about your sharing mode.

Lightning Web Components

Lightning Web Components using Lightning Data Service (wire adapters and LDS functions) automatically enforce both object-level and field-level security. Custom Apex controllers still need proper sharing keywords and FLS checks.

Practical Security Checklist

When setting up security for a new object or feature:

1. Set Organization-Wide Defaults - Start with Private unless you have a specific reason for more open access
2. Configure Profile Permissions - Grant object-level CRUD permissions to appropriate profiles
3. Set Field-Level Security - Make sensitive fields accessible only to users who need them
4. Create Sharing Rules - Grant record access to users and groups that need it
5. Test with Real User Accounts - Verify users can access what they need and cannot access what they shouldn’t
6. Review Apex Security - Ensure custom code enforces sharing and FLS appropriately
7. Document Security Decisions - Record why specific security settings were chosen for future reference

Security vs. Usability

Security and usability exist in tension. Overly restrictive security frustrates users and leads to workarounds that undermine security. Overly permissive security exposes sensitive data and creates compliance risks.

The goal is appropriate security: users should access the data they need to do their jobs, and should not access data they don’t need. This requires understanding:

• What data exists in your org
• Who needs access to which data
• Why they need that access
• How sensitive different data types are
• What regulatory requirements apply

Security is not one-size-fits-all. A healthcare org handling PHI has different requirements than a B2B sales org. A financial services company has different compliance obligations than a nonprofit. Tailor your security model to your organization’s specific needs.

Where to Go From Here

This article covered the fundamentals: the four security layers and how they interact. There’s more depth to explore:

• Permission set groups for managing complex permission combinations
• Territory management for geographic or product-based record access
• Shield Platform Encryption for encrypting data at rest
• Event Monitoring for tracking security-related events
• Security Health Check for identifying security weaknesses

But understanding these four layers gives you the foundation to implement effective data security in Salesforce. Start with appropriate organization-wide defaults, use profiles and permission sets to control object and field access, and layer sharing rules to grant access where needed.

Security isn’t something you configure once and forget. It evolves as your organization grows, as new features are added, and as business requirements change. Regular security reviews ensure your security model continues to match your needs.

---

Tags: #salesforce #security #datasecurity #admin #webdev #tutorial #beginners