# Understanding the Salesforce Security Model


Salesforce stores data that most businesses consider their most sensitive assets — active deal pipelines, full customer histories, support cases, pricing, sometimes financial records. When access control is configured poorly in that environment, the consequences range from data leaks to compliance failures to reps seeing accounts they have no business seeing.

The Salesforce security model is layered by design, and each layer exists for a specific reason. Understanding what each one does — and equally important, what it doesn't do — is what makes the difference between an org that's genuinely secure and one that just looks like it is.

* * *

## The Architecture: Layers That Build on Each Other

Salesforce follows a consistent principle: start with the most restrictive access, then explicitly grant more where needed. The layers work like this:

1.  **OWD (Organization Wide Defaults)** — establishes the baseline. If nothing else applies, what can a user see?
    
2.  **Role Hierarchy** — opens access upward through the management structure automatically
    
3.  **Sharing Rules** — extends access horizontally, across teams and groups
    
4.  **Manual Sharing** — handles genuine one-off exceptions
    
5.  **Profiles** — governs what users can *do* with the records they can access
    
6.  **Permission Sets** — adds targeted permissions on top of profiles without changing the base
    

One rule that governs all of this: access can only be granted through these layers, never removed. If OWD is Public Read/Write and you assign a restrictive profile, users can still see the records — because OWD already granted it. That additive-only behavior is important to understand when debugging unexpected access.

* * *

## Organization Wide Defaults: Setting the Floor

OWD is the first and most fundamental question in Salesforce access: what's the default visibility when no other sharing mechanism applies?

The options for most objects:

**Private** — only the record owner and users above them in the role hierarchy can see the record. Everyone else is locked out unless explicitly granted access through another mechanism.

**Public Read Only** — any user in the org can view the record, but only the owner can edit it.

**Public Read/Write** — any user can view and edit. Appropriate for reference data and non-sensitive objects.

**Controlled by Parent** — used in master-detail relationships. The child record inherits access from the parent.

For anything sensitive — Opportunities, Cases, Accounts in industries with compliance requirements — Private is the right starting point. The instinct to start permissive and tighten later almost never works out cleanly. Restricting access in an org where users are already accustomed to seeing everything creates friction and political resistance that makes security work harder.

**Practical guidance:** OWD rarely needs to change, but it silently becomes wrong when the organizational structure shifts. A division that was one team becomes two, each with different data access needs. Build a review trigger for OWD into any significant org restructuring process.

* * *

## Role Hierarchy: Vertical Access Without Manual Work

Role hierarchy gives managers automatic visibility into records owned by the users beneath them in the hierarchy. A sales director sees every Opportunity their regional managers own. A regional manager sees every Opportunity their reps own. No sharing rules needed — it's structural.

This is Salesforce's primary tool for manager visibility, and it works well when the hierarchy is set up correctly. A few things that matter in practice:

Each user has exactly one role. In organizations with matrix reporting — where someone reports to both a functional manager and a geographic lead, for example — the role hierarchy can only represent one of those dimensions. The other requires sharing rules to cover.

Access granted via role hierarchy flows all the way up the chain. If a rep owns a highly sensitive record, everyone above them in the hierarchy can see it. That's usually appropriate — but it's worth being deliberate about it, especially in orgs where the hierarchy is deep and executives sit at the top of everything.

The role hierarchy is an access model, not a org chart. They should reflect each other, but the driving design consideration should be data access requirements, not visual representation of reporting structure.

**Practical guidance:** Build the role hierarchy against actual access requirements, not a copy of the HR org chart. Validate it by checking what a user in each role can actually see, not just by reviewing the configuration.

* * *

## Sharing Rules: Horizontal Access Across Teams

Role hierarchy handles vertical access — upward through management. Sharing rules handle horizontal access — across teams, regions, and groups who need visibility into each other's records but don't have a management relationship.

There are two types, and the distinction matters:

**Ownership-based sharing rules** trigger automatically based on who owns a record. "Share all Opportunities owned by users in the East Sales role with users in the West Sales role." The sharing happens whenever the ownership condition is met — no record-by-record decisions required.

**Criteria-based sharing rules** trigger based on field values. "Share all Cases where Priority equals Critical with the Senior Support Team." More flexible, but the field value has to actually exist on the record, which creates a dependency on good data quality.

Both types can grant Read Only or Read/Write access, and can target roles, public groups, or territories.

**Practical guidance:** Every sharing rule should be documented with the business reason it exists. This sounds like overhead but it's genuinely necessary — organizations that skip this end up with sharing rules that nobody understands, that can't safely be changed, and that persist long after the team or process that required them no longer exists. The cleanup is painful.

* * *

## Manual Sharing: The Exception Mechanism

Manual sharing lets record owners and admins grant per-record access to specific users or groups, directly from the record itself. It exists for genuine edge cases — a specific customer requests that their account be visible to a colleague outside the normal sharing model, a legal matter needs visibility beyond the standard configuration.

The problem with manual sharing isn't the capability itself — it's what happens to it over time. Manual shares don't expire automatically. They accumulate. After a few years in an active org, the manual sharing landscape becomes a set of access grants that nobody fully understands, many of which are no longer justified by any current business need.

**Practical guidance:** Treat manual sharing as a last resort, not a convenience. Document each instance with who authorized it and why. Review existing manual shares at a regular cadence — quarterly works for most orgs — and remove any that no longer have a clear justification.

* * *

## Profiles: Governing What Users Can Do

OWD, role hierarchy, and sharing rules determine what records a user can see. Profiles determine what they can do once they can see them.

Profiles control:

*   **Object-level permissions** — Create, Read, Edit, Delete on a per-object basis, plus View All and Modify All for administrative purposes
    
*   **Field-level security** — which specific fields within an object a user can see and edit
    
*   **Page layouts and record types** — how the record appears and which record types the user can work with
    
*   **App and tab visibility** — which parts of the Salesforce interface are accessible
    

Every user has exactly one profile. It sets the permission ceiling for most things — permission sets can add capabilities on top, but for certain system-level permissions, the profile is the hard boundary.

The most common mistake in profile management is proliferation. Organizations that create a distinct profile for every team variation end up with thirty profiles where five would have done, most of them nearly identical, all of them needing to be maintained separately whenever Salesforce releases a new permission. A more maintainable approach: fewer profiles scoped to broad job functions, with permission sets handling the variations.

**Practical guidance:** Audit profiles against actual current job responsibilities, not what was accurate when the profile was originally created. People change roles, pick up temporary access, move between teams. Permissions accumulate. An annual review of profile assignments is the minimum; quarterly is better for faster-moving orgs.

* * *

## Permission Sets: Precise Additions Without Profile Changes

Permission sets grant specific permissions to individual users on top of their profile — without changing the profile itself. The classic scenario: a sales rep who's also responsible for certain reporting needs read access to financial objects that the standard Sales profile doesn't include. Creating a new profile for one person, or modifying the existing profile for everyone who uses it, are both wrong answers. A permission set is the right one.

Permission Set Groups, available in recent Salesforce releases, let you bundle multiple permission sets into a single assignment. Useful when several permissions always need to travel together — instead of assigning five permission sets individually, you assign one group.

**Practical guidance:** Permission sets need the same governance discipline as profiles. Clear naming conventions, documented purpose, and regular review of who's assigned what. An assigned permission set that outlives the business reason for it is an access gap — and unlike manual shares, they don't show up in sharing audit reports.

* * *

## Field Level Security: Within-Record Data Protection

Field Level Security operates independently of record-level access. A user can have full visibility into an Account record and still be unable to see specific fields — Annual Revenue, a custom Social Security Number field, proprietary discount rates — because FLS is set to hidden for their profile.

FLS is configured at the profile level and can be extended via permission sets. A field hidden for a profile can be made visible to specific users through a permission set, without changing the profile for everyone else.

This matters most for regulated data. Healthcare orgs need it for PHI fields. Financial services need it for compensation data. Any org with sensitive PII should be using FLS to protect individual fields, not relying solely on record-level access controls.

**Practical guidance:** FLS is frequently the gap identified in Salesforce security audits — not because admins don't know it exists, but because new fields get added to objects without a corresponding FLS review. Make FLS configuration an explicit step in any new field deployment process.

* * *

## The Security Model in Practice

A few things that are true in most production Salesforce orgs worth stating plainly:

Starting permissive and trying to lock down later is much harder than starting restrictive and opening up deliberately. The pushback from users who lose access they're accustomed to is real, and it tends to derail security initiatives.

Access accumulates. Users change roles, pick up permissions for projects, get manual shares for deals that close. Without regular audits, the effective access in an org drifts significantly from what was intentionally designed.

Sharing rules that aren't documented become permanent. Nobody wants to remove a rule they don't understand — what if something breaks? The result is an access configuration that gradually becomes more permissive over time.

The layers interact. A misconfiguration at OWD can make every sharing rule irrelevant. A profile that grants Modify All on an object overrides every record-level restriction below it. Understanding the system as a whole, not just each component in isolation, is what makes the security model actually work.

* * *

## Working on Salesforce Architecture or Security?

At Innostax, we build with both — the choice comes from what the project actually needs, not what we happen to prefer. Whether that's a greenfield Salesforce implementation, a security audit of an existing org, or untangling access configuration that's grown complicated over time — the approach follows what the business actually requires.

If you're figuring out the right stack for something you're building, [innostax.com/contact](https://innostax.com/contact) is the right place to start that conversation.

*Originally published on the* [*Innostax Engineering Blog*](https://innostax.com/blog/understanding-the-salesforce-security-model/)*.*