Salesforce Data Security

Salesforce's security model works in layers — like an onion. Each layer adds more control over who can access which data. The three most important layers beyond Profiles and Roles are Permission Sets, Organization-Wide Defaults (OWD), and Sharing Rules. Together, these tools let administrators give the right people the right access — nothing more, nothing less.

The Security Onion Model

  OUTERMOST → Organization-Wide Defaults (the baseline — most restrictive)
             → Role Hierarchy (opens access upward in the org chart)
             → Sharing Rules (opens access for specific groups)
             → Manual Sharing (one-off record sharing)
  INNERMOST → Permission Sets (adds individual extra permissions)

Each layer can only open access — never restrict it more than the outer layer. You set the most restrictive baseline first (OWD), then progressively open access for those who need more.

Organization-Wide Defaults (OWD)

OWD sets the baseline level of access for every object across the entire organization. It answers the question: "If no other rule applies, what can a user see?"

You configure OWD in Setup under Security → Sharing Settings. For each object, you choose one of these access levels:

Choosing the Right OWD

Start with the most restrictive setting that makes sense for the object. For Opportunities, most companies use Private — salespeople should not see each other's deals by default. For Products or Pricelists, Public Read Only makes sense — everyone needs to see what the company sells.

Sharing Rules

When OWD is set to Private but a group of users still needs access to certain records, you create Sharing Rules. A Sharing Rule automatically grants record access to a specific set of users based on a criteria.

Two Types of Sharing Rules

Owner-Based Sharing Rules

These rules share records based on who owns them. Example: "Share all Opportunities owned by the West Region role with the East Region role." This is useful when two teams need visibility into each other's deals.

Criteria-Based Sharing Rules

These rules share records based on field values. Example: "Share all Accounts where Industry = 'Healthcare' with the Healthcare Specialist team." Any Account that meets the criteria is automatically shared — regardless of who owns it.

  OWD: Accounts = Private
  Sharing Rule: IF Account.Industry = "Healthcare"
                THEN share with Healthcare Specialists Group
                (Read Only access)

  Result: Healthcare Specialists see all healthcare Accounts
          even those they do not own.

Manual Sharing

Sometimes a user needs access to one specific record — not a whole group of them. A record owner (or administrator) can grant access to one record at a time using the Share button directly on the record. This is called Manual Sharing. It is flexible but does not scale well — avoid using it as a long-term solution for large teams.

Permission Sets

A Permission Set is a collection of extra permissions you assign to individual users on top of their Profile. While Profiles provide the standard access for a job role, Permission Sets handle exceptions.

A Real-World Example

Imagine a sales team where all reps share the "Standard Sales Profile." One rep — Anil — is asked to temporarily help the marketing team and needs access to Campaign records. Instead of changing Anil's Profile (which would affect the rest of the team if they used a shared profile), you create a Permission Set called "Campaign Access" and assign it to Anil alone.

  Standard Sales Profile (all sales reps)
  → Read/Create/Edit: Accounts, Contacts, Opportunities
  → No access to Campaigns

  + Permission Set: Campaign Access (assigned to Anil only)
  → Read/Create/Edit: Campaigns

  RESULT: Anil can access Campaigns. Other reps cannot.

Permission Set Groups

When you regularly assign multiple Permission Sets together, you bundle them into a Permission Set Group. Instead of assigning five separate Permission Sets to new employees, you assign one Permission Set Group that includes all five. This simplifies user setup and ensures consistency.

Field-Level Security

Field-Level Security (FLS) controls whether a specific field is visible or editable for users with a given Profile or Permission Set. Even if a user can see an Account record, specific sensitive fields — like Annual Revenue or Credit Score — can be hidden from them entirely.

FLS settings live inside the Profile and Permission Set configuration. Every field on every object has its own FLS settings: Hidden, Read Only, or Read/Write.

The Security Checklist for Administrators

• Set OWD as restrictive as possible for each object.
• Use the Role Hierarchy to give managers visibility over their team.
• Use Sharing Rules for group-level access exceptions.
• Use Permission Sets for individual access exceptions.
• Use Field-Level Security to hide sensitive fields from users who should not see them.
• Never rely on manual sharing as a long-term access strategy.

Key Points

• OWD sets the baseline access for every object — always start restrictive and open access as needed.
• Sharing Rules automatically extend record access to groups of users based on ownership or field criteria.
• Permission Sets add extra permissions to individual users without changing their Profile.
• Field-Level Security controls visibility and editability of specific fields per Profile or Permission Set.
• The security model only opens access — each layer builds on the previous one and never restricts further than OWD.