Data Security in Salesforce — The Full Architecture Explained Deeply

The Full Architecture 

Before touching any configuration, understand one fundamental principle:

Salesforce security is layered and sequential.

Access is not decided in one place. It is evaluated step by step. If access fails at any layer, the user stops there — even if other layers would allow access.

Think of it like passing through four security checkpoints.

These four levels are:

1. Organization Level

2. Object Level

3. Field Level

4. Record Level

Each level answers a different question.

Let’s go deeper.

────────────────────────

1. Organization-Level Security — “Can You Enter the System?”

This is the outer boundary.

It controls authentication and access to the org itself, not data visibility.

Configured in:
Setup → Password Policies
Setup → Login Access
Setup → Network Access

What you control here:
• Who is an active user
• Password strength rules
• Login hours
• IP address restrictions
• Multi-factor authentication

Important clarification:
This level does NOT decide what data someone sees. It only decides whether they can log in.

Common confusion:
Authorized User Lists are organization-level control.
They are not related to objects or records.

If login fails here, nothing else matters.

────────────────────────

2. Object-Level Security — “Can You Use This Type of Data?”

Once inside, Salesforce checks object permissions.

An object is like a database table:
Accounts, Opportunities, Job Applications, Custom Objects.

Object-level security answers:
Can the user Create?
Can the user Read?
Can the user Edit?
Can the user Delete?

These are called CRUD permissions.

Configured using:
Profiles
Permission Sets
Permission Set Groups

Location:
Setup → Profiles
Setup → Permission Sets

Very important concept:
If object access is denied, record-level sharing does not matter.

Example:
OWD = Public Read/Write
But object permission = No Read

Result:
User still cannot see any record.

Object-level access is a gate before record access.

Exam trap:
Profiles and Permission Sets control object-level access.
Sharing rules do NOT.

────────────────────────

3. Field-Level Security — “Can You See This Specific Piece of Data?”

Even if someone can access an object, they may not be allowed to see every field.

Example:
Recruiter can access Job Application.
But Salary field should only be visible to HR.

Field-level security allows:
• Field Visible or Hidden
• Field Read-Only

Configured in:
Profile or Permission Set → Object Settings → Field Permissions

Critical rule:
Field-level security overrides page layout.

If field is hidden at security level:
• It will not appear on page layout
• It will not appear in reports
• It will not be accessible via API
• It will not be accessible in flows

Page layout cannot override field-level security.

Exam trap:
If field visible on layout but hidden in field security → user cannot see it.

────────────────────────

4. Record-Level Security — “Which Specific Records Can You See?”

Now we go deep.

This is where most confusion happens.

Object-level decides:
Can you access Job Application object?

Record-level decides:
Which job applications inside that object can you access?

This is controlled in four stages.

────────────

A) Organization-Wide Defaults (OWD) — The Baseline Rule

Location:
Setup → Sharing Settings

OWD sets the default visibility of records between users.

Options:
Private
Public Read Only
Public Read/Write

If OWD = Private:
Users can only see records they own.

If OWD = Public Read Only:
Users can see all records but edit only their own.

If OWD = Public Read/Write:
Users can see and edit all records.

Very important principle:
OWD sets the minimum access.

Best practice:
Start with Private.
Then expand access using other tools.

OWD restricts.
Other tools expand.

────────────

B) Role Hierarchy — Vertical Access

Location:
Setup → Roles

Users higher in the hierarchy inherit access to records owned by users below them.

Example:
Recruiter reports to Hiring Manager.
Hiring Manager automatically sees recruiter’s records.

Key understanding:
Role hierarchy does not grant access sideways.
Only upward.

Also:
If OWD is Public Read/Write, role hierarchy becomes irrelevant.

────────────

C) Sharing Rules — Automatic Exceptions

Location:
Setup → Sharing Settings → Sharing Rules

Used to grant access horizontally.

Example:
All West Region recruiters can see West Region records.

Sharing rules:
• Automatically grant access
• Based on roles, public groups, or criteria
• Never restrict access

Common trap:
Sharing rules cannot remove access.
They only add.

────────────

D) Manual Sharing — One Record at a Time

The record owner manually shares a specific record with another user.

Use case:
Recruiter going on leave shares one application.

Manual sharing:
• Is per record
• Not automated
• Depends on object settings

────────────

Now here is the complete mental model.

When user opens a record, Salesforce checks:

1. Can they log in? (Organization Level)

2. Do they have object permission? (Object Level)

3. Do they have field permission? (Field Level)

4. Does record sharing allow this specific record?
   → OWD baseline
   → Role hierarchy
   → Sharing rules
   → Manual sharing

If any step fails → access denied.

That is the full security pipeline.

────────────────────────

Security Applies Everywhere

Another critical concept:

Salesforce security is enforced at the API level.

This means:
Even if someone uses Data Loader, API integration, or custom code — all these security rules still apply.

Security is not just UI-based.
It is platform-level.

This prevents bypassing restrictions.

────────────────────────

Auditing — Monitoring the System

Security is not only prevention.
It is also monitoring.

Salesforce provides:

Record Modification Fields
Automatically tracks Created By and Last Modified By.

Login History
See successful and failed logins (last 6 months).

Field History Tracking
Tracks changes to selected fields.
Configured in:
Object → Fields & Relationships → Set History Tracking

Setup Audit Trail
Tracks configuration changes.
Setup → View Setup Audit Trail

Event Monitoring
Advanced tracking of user behavior patterns.

These tools help detect abnormal activity.

────────────────────────

Control Access to the Org — The True Outer Wall

────────────────────────

Before thinking about data security, understand this:

If the wrong person can log in, everything else becomes meaningless.

So organization-level security answers one primary question:

Who is allowed to access this Salesforce org, and under what conditions?

It operates at the authentication and login layer.

This layer includes:

• User management
• Password policies
• IP-based restrictions
• Time-based restrictions

Everything here happens before object-level security even begins.

────────────────────────

1. User Management — Identity is the Starting Point

Every user in Salesforce has:

• A unique Username (must look like an email, globally unique across Salesforce)
• A Password
• Exactly one Profile
• One User License
• Optional Permission Sets

Location:
Setup → Users

Critical understanding:

The User License determines what type of access framework the user can have.
The Profile defines default permissions and login restrictions.
Permission Sets extend permissions beyond the profile.

You cannot create a user without assigning:
• License
• Profile

That is architectural enforcement.

Important distinction:

You cannot delete a user in Salesforce.
You can only deactivate them.

Why?

Because user records are tied to data ownership and audit history. Deleting a user would break historical data integrity.

Deactivation removes login access but preserves:
• Record ownership history
• Created By / Last Modified By fields
• Reporting references

If you cannot deactivate immediately (for example, the user is referenced in a hierarchy field), you freeze the user first.

Freeze = Temporarily blocks login.
Deactivate = Fully disables account.

Exam trap:
Freeze is not the same as deactivate.

────────────────────────

2. Password Policies — Controlling Credential Strength

Location:
Setup → Password Policies

Password policies define the complexity and lifecycle of user credentials.

You control:

• Minimum password length
• Required character types (uppercase, numeric, special characters, etc.)
• Password expiration duration
• Login attempt limits before lockout
• Lockout duration

Architectural concept:

Org-wide password policies apply to all users.

However, profile-level password policies override org-wide settings for that specific profile.

That means:

Profile password policy > Org password policy (for users of that profile)

This is a hierarchy of control inside authentication.

Also important:

Users with “Password Never Expires” permission are exempt from expiration rules.

Exam trap:
If both org-level and profile-level password policies exist, the profile-level setting takes precedence.

────────────────────────

3. Trusted IP Ranges (Org Level) — Verification Bypass

Location:
Setup → Network Access

Here, you define IP ranges considered trusted for the entire organization.

What this does:

If a user logs in from a trusted IP range:
• No identity verification challenge is required.

If outside trusted range:
• User must verify identity (e.g., via verification code).

Important distinction:

Trusted IP ranges DO NOT block login.

They only remove the need for identity verification.

User can still log in from outside the range — they just go through verification.

This is commonly misunderstood.

Think of this as:
“Comfort zone” login.

────────────────────────

4. Login IP Restrictions (Profile Level) — Hard Block

Location:
Setup → Profiles → Login IP Ranges

This is different from trusted IP ranges.

Profile-level IP restriction means:

If user logs in from outside the defined IP range:
• Login is completely blocked.
• No verification option.
• No bypass.

This is a strict boundary.

Comparison:

Org Trusted IP Range → Allows login with verification outside range.
Profile IP Restriction → Completely blocks login outside range.

Exam trap:
These two are not the same feature.

────────────────────────

5. Login Hours — Time-Based Access Control

Location:
Setup → Profiles → Login Hours

You can restrict login times for each profile.

Example:
Call center employees can log in only 9 AM – 5 PM.

If login attempt is outside defined hours:
• Login fails.

If user is already logged in when hours expire:
• They can view current page
• They cannot perform further actions

This prevents operational misuse outside working hours.

Architectural logic:

Login hours are profile-based.
So they apply to all users assigned that profile.

────────────────────────

Putting It All Together — Organization-Level Control Flow

When someone tries to log in, Salesforce evaluates:

1. Is user active? (Not deactivated or frozen)

2. Are credentials valid?

3. Has password expired?

4. Has login attempt limit been exceeded?

5. Is login within allowed hours?

6. Is login from allowed IP range (profile restriction)?

7. If outside trusted IP range → require identity verification.

Only after all these checks succeed does the user enter the system.

Only then do object, field, and record-level checks begin.

Control Access to Objects — The Practical Architecture

Now that the outer wall (org-level security) is secure, the next question is:

Inside the system, what type of data can a user work with?

This is object-level security.

An object is simply a table of records:
Account, Opportunity, Position, Candidate, Job Application, Review.

Object-level security answers one clear question:

Can this user Create, Read, Edit, or Delete records of this object?

These four permissions are called CRUD:
Create
Read
Edit
Delete

Everything at object-level revolves around these.

If Read is not enabled → user cannot even see the object.
If Create is not enabled → user cannot create new records.
If Delete is not enabled → user cannot remove records.

This layer is absolute. If object access is denied, record sharing later is irrelevant.

Now let’s go practical.

────────────────────────

Where Object Permissions Are Configured (Real Admin View)

You have three main tools:

1. Profiles

2. Permission Sets

3. Permission Set Groups

Each serves a different architectural purpose.

────────────────────────

Profiles — The Base Identity

Every user must have exactly one profile.

Location:
Setup → Profiles

Profiles define:
• Default object permissions
• Login hours
• IP restrictions
• App visibility
• Page layouts
• Record types

Important practical limitation:

Standard profiles cannot have object permissions edited.
You must clone them first.

How to clone a profile (step-by-step):

1. Setup → Profiles

2. Click “Clone” next to an existing profile (example: Minimum Access – Salesforce)

3. Give new profile a name

4. Save

5. Edit object permissions under “Object Settings”

However, modern best practice is:

Use profiles only for base access.
Use permission sets for functional access.

This avoids creating dozens of custom profiles.

────────────────────────

Permission Sets — The Functional Building Blocks

Location:
Setup → Permission Sets

A permission set is a reusable block of permissions.

Best practice mindset:
Each permission set should represent a task, not a person.

Example:
“Manage Positions”
“Manage Reviews”
“Lead Deletion Access”

Users can have multiple permission sets.

How to create one (exact steps you’ll follow in real org):

1. Setup → Permission Sets

2. Click New

3. Label: Manage Positions

4. License: –None– (important if you want flexibility)

5. Save

6. Under “Object Settings” → Click Positions

7. Click Edit

8. Enable Read, Create, Edit

9. Save

Now this permission set grants CRUD for Positions.

That’s it. Simple but powerful.

────────────────────────

Permission Set Groups — The Persona Layer

Permission sets are tasks.

Permission set groups are personas.

Location:
Setup → Permission Set Groups

Think like this:

Recruiter persona =
• Manage Positions
• Manage Candidates
• Manage Job Applications
• Manage Reviews

Instead of assigning 4 permission sets manually to each recruiter,
you create one permission set group called “Recruiters”.

Steps to create:

1. Setup → Permission Set Groups

2. Click New

3. Label: Recruiters

4. Save

5. Click “Permission Sets in Group”

6. Click Add Permission Set

7. Select the required permission sets

8. Add

Then assign to users:

1. Open the Permission Set Group

2. Click Manage Assignments

3. Add Assignment

4. Select users

5. Assign

Now the user inherits all included permissions.

This is scalable design.

────────────────────────

Real Recruiting App Architecture (Deep Thinking)

Now let’s think like an architect, not just follow Trailhead.

You have 4 personas:

Recruiter
Hiring Manager
Interviewer
Standard Employee

Instead of creating 4 custom profiles, do this:

1. Assign everyone Minimum Access – Salesforce profile.

2. Build functionality using permission sets.

3. Combine them into permission set groups.

Why?

Because profiles are rigid.
Permission sets are modular.

This allows:
• Easy addition of new permissions
• Temporary access via expiration dates
• Clean removal of permissions

────────────────────────

Critical Real-World Considerations

Recruiters must not delete records.

So when creating permission sets:
Do NOT enable Delete on Candidate or Job Application.

Because of compliance laws, delete permission must be controlled strictly.

Exam trap:
If Delete is enabled at profile or permission set → user can delete regardless of sharing rules.

Object permission always overrides record-level sharing.

────────────────────────

System Administrator Special Case

System Administrator profile includes:

View All Data
Modify All Data

These permissions override sharing.

Even if OWD = Private,
System Admin sees everything.

Never casually assign System Administrator profile.

────────────────────────

Reviewing Access (Most Ignored but Very Important)

After configuring permissions, always verify.

Object-level summary:

Setup → Object Manager → Select Object → Object Access

This shows:
• Which profiles grant access
• Which permission sets grant access
• Which permission set groups grant access

User-level summary:

Setup → Users → Select User → View Summary

This shows:
• Exactly how access is granted
• Whether from profile or permission set

This is critical for debugging real-world issues.

If a user has unexpected access,
this summary tells you why.

────────────────────────

Your Hands-On Challenge — What You Actually Do

You are asked to:

Create Permission Set:
Label: Manage Positions
API Name: Manage_Positions
License: –None–
Enable Read, Create, Edit on Positions

Then:
Add it to Recruiters Permission Set Group.

Why?

Because in this architecture:
Recruiters need full management of Positions.

Then verification step:
Check Object Access Summary for Position object.
Confirm both:
• Manage Positions Permission Set
• Recruiters Permission Set Group

appear.

This proves the access is layered correctly.

────────────────────────

Architectural Summary — Object Level

Object-level security decides:
Can a user work with this type of data?

Configured through:
Profiles (base)
Permission Sets (task)
Permission Set Groups (persona)

Best practice:
Keep profiles minimal.
Use permission sets modularly.
Bundle with permission set groups.

Never overuse System Administrator.
Never grant Delete casually.
Always verify using access summaries.