Understanding the Salesforce Security Model

Sensitive data sits at the core of every Salesforce org. Protecting it takes a strong security model. This article breaks down the key pieces of that model, and how they work together.

These pieces include Organization-Wide Defaults (OWD), Object Level Security (OLS), Field Level Security (FLS), Profiles, and Permission Sets. Together, they form a layered defense that protects data confidentiality, integrity, and accessibility.

Salesforce Security Model

Salesforce security is built in layers. Each layer covers a different part of data access, from broad org-wide rules down to individual fields.

Organization Wide Defaults (OWD)

OWD sits at the center of the security model. It sets the baseline level of access across the whole org. These settings decide the default visibility of records.

This setup makes sure users only see data relevant to their role. It creates a secure, role-specific environment with the right level of access and control.

Implementation Tip:

Regularly review and adjust OWD settings based on organizational changes to maintain an optimal balance between data security and accessibility.

Object Level Security (OLS)

Object Level Security controls whether a user can access a particular type of record at all — Accounts, Opportunities, or a custom object. This is independent of which specific records they can see. OWD determines visibility at the record level. OLS operates one level up, at the object level itself.

If a user has no OLS access to the Opportunity object, it does not matter what OWD or sharing rules say. The user simply cannot access that object type at all.

OLS is controlled through Profiles and Permission Sets via the “Object Permissions” settings. These govern whether a user can create, read, edit, or delete records of a given object type.

This is a common source of confusion during troubleshooting. Admins often check sharing rules and role hierarchy first. But the real cause is often that OLS never granted access to the object in the first place.

Implementation Tip:

Before troubleshooting record-level visibility issues, confirm Object Level Security first — it’s the most basic access gate, and skipping this check is a common cause of misdiagnosed permission issues.

Field Level Security (FLS)

Field Level Security controls visibility and editability at the individual field level. It’s even more specific than Object Level Security. A user might have full access to the Account object, but still be blocked from viewing one specific field, like an internal credit rating or a compliance flag that doesn’t apply to their role.

FLS is set through Profiles and Permission Sets, just like OLS, but it applies per field instead of per object. This makes it useful for protecting sensitive data. For example, a sales rep might need full access to an Account record, but shouldn’t see an internal risk field meant only for the finance team.

Since FLS settings live separately on every profile and permission set, they can be hard to audit at scale. That’s why reviewing FLS regularly matters just as much as reviewing OWD.

Implementation Tip:

Build a field-sensitivity map first — a simple record of which fields hold sensitive data, and which roles should see them. Do this before configuring FLS across multiple profiles, rather than making field-by-field decisions with no reference point.

Role Hierarchy

Role Hierarchy defines the chain of command in your org. It reflects reporting relationships, especially for sales and support teams. Roles higher up the chain can see and manage data owned by roles below them.

This keeps information flowing efficiently. Employees get the access they need, while security and privacy stay intact. Role Hierarchy plays a key role in managing Salesforce data in line with how your business is actually structured. It’s especially useful in sales orgs, where managers often need visibility into their team’s open deals without owning the records themselves.

Implementation Tip:

Understand the organization’s reporting structure and determine how roles align hierarchically.

Sharing Rules

Sharing Rules extend record-level access beyond your default OWD settings. They let admins fine-tune visibility based on specific criteria. You can share records with users, roles, public groups, or territories, based on fields, ownership, or other record details.

There are two types. Ownership-based sharing rules work automatically, based on who owns a record. Criteria-based sharing rules apply based on conditions you define. Both types help data access match your organization’s real needs, while keeping security and privacy strong. Used well, Sharing Rules cut down on manual work by handling common access patterns automatically.

Implementation Tip:

Tailoring criteria based on scenarios and user needs determines the suitable groups or individuals for sharing records accurately.

Manual Sharing

Manual Sharing lets admins and record owners grant specific users or groups access to a single record. It’s set directly from the record itself. Access can be Read-Only or Read/Write.

Manual Sharing works well for exceptions and one-off cases. But use it carefully. Too many undocumented manual shares build up into a structure that’s nearly impossible to audit. Regular review and clear documentation keep things transparent and aligned with business needs. Think of it as a last resort, not a substitute for well-designed sharing rules.

Implementation Tip:

An essential recommendation: Establish guidelines and documentation for authorized manual sharing circumstances and the designated individuals or groups.

Profiles

Profiles are a core part of the Salesforce Security Model. They define what actions users can take across the org, including field access, page layouts, and record types.

Profiles set clear boundaries for what each user can do, based on their role. This makes sure every user works in Salesforce with access that fits their actual job. A well-designed set of profiles also makes onboarding new employees much faster.

Implementation Tip:

Match profiles with job roles, ensuring users have the right permissions to perform their tasks efficiently and effectively.

Permission Sets

Profiles give users a broad set of permissions. Permission Sets add flexibility on top of that. They grant specific extra permissions to individual users, without changing their underlying profile.

This modular setup gives admins precise control. They can add extra access for specific users without touching the core profile structure. This lets an organization adapt quickly to changing needs, while keeping its profile setup clean and simple. It’s often the better choice over creating a brand-new profile for a single exception.

Implementation Tip:

Use Permission Sets to handle unique access needs. This keeps permission management flexible, without adding unnecessary profiles.

Login Access Policies and Session Security

Everything covered so far controls what an already-authenticated user can see and do. A separate layer controls who can log in at all.

Login IP ranges can restrict access to specific networks. This matters for organizations that want to block access from outside a corporate VPN.

Session settings control how long a session stays active, whether users can have multiple sessions running at once, and whether a session survives a browser restart.

Multi-factor authentication (MFA) is now a baseline requirement, not an optional extra, especially for orgs handling regulated data. MFA doesn’t replace OWD, OLS, or FLS. A user who logs in successfully is still subject to every other security layer. But if login access isn’t locked down properly, none of those other layers ever get the chance to do their job.

Common Misconfigurations That Undermine the Security Model

Even a well-designed security model can fail in practice. Here are the most common mistakes to watch for:

• OWD set too loosely. Defaulting to Public Read/Write across the org, just because it’s easier than diagnosing access complaints. This quietly undoes most of the security model’s purpose.
• Over-reliance on Manual Sharing. A handful of manual shares is fine. But hundreds of undocumented shares, built up over years, become a structure no one can audit or explain.
• Profile sprawl. Creating a new, nearly identical profile for every small variation in access needs. It’s better to use fewer profiles and handle exceptions with Permission Sets instead. Profile sprawl makes an org harder to maintain, and increases the risk of accidentally affecting the wrong team when a profile changes.

Wrapping Up

Understanding the Salesforce Security Model means understanding how OWD, OLS, FLS, Profiles, and Permission Sets work together. A strong security strategy protects your data, aligns access with real organizational roles, and helps guard your org against threats.

As your business evolves, your security needs will too. Regular audits, reviews, and updates keep your security model effective over time. They protect your organization’s most valuable asset: its data. A well-maintained Salesforce security model lets your business move forward with confidence.