How to Set Up Salesforce Security: A Complete Guide
Salesforce security isn't one setting — it's six layers stacked on top of each other. Get one wrong and you've either locked out your sales team or exposed your customer database.
This guide walks each layer, the order to set them in, and the mistakes that turn security from "controlled access" into "everybody can see everything."
Estimated read time: 13 minutes
The Salesforce security model in 60 seconds
Salesforce security has six layers. Each one tightens or loosens what users can see and do:
- Organization-Wide Defaults (OWDs) — the baseline access for each object (Public Read/Write, Public Read Only, Private)
- Role Hierarchy — managers see what their reports see
- Sharing Rules — exceptions that grant additional access
- Profiles — what objects, fields, and settings a user can access
- Permission Sets — additional permissions on top of the profile
- Field-Level Security (FLS) — visibility per field
Set them in that order: OWDs first, then layer access on top. If you start with profiles and skip OWDs, you'll never feel in control.
Layer 1: Organization-Wide Defaults
OWDs set the most restrictive access a user could have to an object's records. Other layers can only loosen, never tighten.
Three settings per object:
- Public Read/Write: Anyone can see and edit any record
- Public Read Only: Anyone can see; only owner (and people above in hierarchy) can edit
- Private: Only the owner (and people above in hierarchy) can see
Recommended starting point for most B2B orgs:
- Account: Public Read Only
- Contact: Controlled by Parent (inherits Account)
- Opportunity: Private
- Lead: Private (with assignment rules)
- Cases: Private
Set OWDs from Setup → Sharing Settings.
Layer 2: Role Hierarchy
The role hierarchy is not your org chart. It's a sharing structure: people in higher roles automatically see records owned by people in lower roles.
A common mistake: building a role for every job title. Don't. Roles exist for sharing, not for HR. Most B2B orgs need 5-10 roles total.
Build it from Setup → Roles.
Layer 3: Sharing Rules
When OWDs say Private but you need exceptions ("the West region team should see all West Coast Opportunities"), use sharing rules.
Two types:
- Owner-based: "Records owned by users in Group A are shared with users in Group B"
- Criteria-based: "Records where Region = West are shared with the West Sales group"
Create from Sharing Settings → scroll to the object → New under Sharing Rules.
Layer 4: Profiles
A profile defines:
- Which objects a user can access (CRUD: Create, Read, Update, Delete)
- Which apps they can see
- Which page layouts and record types apply
- Which tabs are visible
- Which fields they can see (default FLS — overrideable per field)
- Login hours and IP restrictions
Salesforce recommends keeping the number of profiles small. Use the Minimum Access — Salesforce profile as the baseline and grant additional permissions via permission sets.
Layer 5: Permission Sets
Permission sets grant additional permissions on top of the profile. They never restrict.
Use cases:
- Grant a sales rep temporary access to a Marketing object
- Give a specific user export permission without changing their profile
- Grant API access to integration users without changing the base profile
Best practice: every recurring permission combination becomes a permission set. Assign sets to users via assignments or groups.
For a deeper comparison: see our guide on Permission Sets vs Profiles.
Layer 6: Field-Level Security
FLS controls visibility per field, per profile.
Two settings per field per profile:
- Visible (or hidden)
- Read-Only (or editable)
Set FLS when creating new fields (the wizard asks). To audit existing fields: Object Manager → object → Fields & Relationships → field → Field Accessibility.
The 7 most common security mistakes
- OWDs set to Public Read/Write for everything. Defeats the entire model. Audit every object.
- Too many profiles. 30+ profiles means nobody knows what changes will affect whom. Consolidate.
- Profiles with "Modify All Data." Grants access to everything regardless of OWDs. Use only for system administrators.
- Sharing rules that contradict. Two rules that grant overlapping access make audits impossible.
- Field-level security skipped on new fields. Default visibility is "everyone." That's a problem the day you add a Cost field.
- Login hours/IP not set. Compliance auditors will flag this. Set login hour restrictions for non-admin profiles.
- API access granted via profile, not permission set. When the integration user changes, you have to clone an entire profile.
Compliance considerations
If you're SOC 2, HIPAA, or GDPR-regulated:
- Enable Multi-Factor Authentication for all users (Setup → Identity → MFA)
- Set Session Settings to expire after 2 hours of inactivity
- Enable Field Audit Trail on sensitive fields
- Use Shield Encryption for PII at rest (separate license)
- Run Health Check monthly (Setup → Health Check) and remediate findings
Want a security audit done for you?
A proper Salesforce security review — OWDs, profiles, permission sets, sharing rules, FLS, login policies — takes a senior Salesforce admin 2-3 weeks. Most orgs have never had one.
RevKit's Security Audit delivers it in 48 hours for $1,499:
- Full audit across all six layers
- Specific findings with severity ranking
- Remediation plan with implementation estimates
- Optional implementation add-on