The digital landscape for enterprise software education and credential preparation is characterized by intense competition, rapid technological iteration, and highly sophisticated search behavior. Practitioners globally are actively seeking clarity on the hybrid state of user management, attempting to decipher which features remain anchored to the profile and how to architect minimum access models.

Whether you are preparing for your next exam and looking for Salesforce security model exam questions , or you are an administrator figuring out how to troubleshoot salesforce profile access issues, understanding the platform’s security architecture is non-negotiable. At CertifySF, our high-volume, scenario-based practice exams across all Salesforce certifications are designed to help you master these exact operational realities.

Salesforce enforces security in a strict top-down hierarchy. A user must pass every layer to access data. Here is exactly how that evaluation happens, from the first gate to the last.

Layer 1: Object-Level Security (OLS)

This is the first gate. Before you can worry about specific records or fields, the system checks if you even have the right to look at the database table itself.

• It is controlled by Profiles and Permission Sets.
• OLS determines whether a user can even see or interact with an entire object—the CRUD permissions (Create, Read, Update, Delete).
• If a user’s Profile doesn’t grant Read on the Case object, for example, the user cannot see Cases at all.

What happens if access fails? No related list, no tab, no records. Nothing downstream matters. This layer is the absolute gatekeeper for everything else.

As the ecosystem navigates how to migrate profiles to permission sets Salesforce , the core debate of Salesforce Profile vs Permission Set 2026 centers heavily on this layer. While the strict retirement of permissions on profiles has been officially postponed, the official architectural recommendation remains a definitive migration toward permission sets for scalability and security.

Layer 2: Record-Level Access

Once a user passes Layer 1 (they have at least Read on the object), Layer 2 determines which specific records of that object they can see. This is where the sharing model comes into play.

• Organization-Wide Defaults (OWD): Sets the baseline. If OWD is Private, users can only see records they own.
• Role Hierarchy: Opens access upward. A manager can see records owned by anyone below them in the hierarchy.
• Sharing Rules: Open access laterally. You can share records between roles, groups, or territories that aren’t in a direct hierarchy.
• Manual Sharing / Apex Sharing: One-off sharing of individual records, or programmatic sharing via code.
• Teams: Account Teams, Opportunity Teams, and Case Teams grant access to specific users on specific records.

What happens if access fails? The user will be able to see the object tab, but they will not see the specific record in list views or searches. If they are given a direct link to a record they don’t have access to, they will hit an error. When diagnosing a Salesforce insufficient privileges error profile issue, it is critical to cleanly distinguish between this record-level sharing and object-level CRUD.

The key principle here is that Layer 2 can only open up access beyond the OWD baseline. It can never restrict access below OWD.

Layer 3: Field-Level Security (FLS)

Once a user passes Layer 1 (they can access the object) and Layer 2 (they can access the specific record), FLS determines which fields on that record they can see or edit.

• FLS is set on Profiles and Permission Sets.
• FLS can make a field visible-only or completely hidden—regardless of what’s on the page layout.

What happens if access fails?

The user will successfully open the record, but the specific restricted field will simply not be there. If a process or flow tries to update that field in a user context without FLS, it will fail.

Layer 4: Page Layouts

This is the final presentation layer.

• Page layouts control what fields, related lists, and buttons appear on the screen for a given Profile/Record Type combination.
• Page layouts are not a security mechanism—they’re a UI convenience.
• If a field is on a page layout but FLS hides it, the user won’t see it.

What happens if access fails? You cannot fail “access” at the page layout level because it does not control database security. Even if a field is removed from a page layout, it can still be accessed through reports, list views, or the API if FLS allows it.

Securing Your Ecosystem

The critical exam takeaway is that each layer is evaluated in order, and a failure at any earlier layer makes all later layers irrelevant. This layered architecture is a frequent topic in Salesforce scenario based interview questions security assessments, and proving your mastery of it is a highly impactful addition to your Salesforce Administrator resume keywords.

To summarize the entire stack in one sentence: Profile/Permission Set (OLS) decides if you can access the object, OWD + Hierarchy + Sharing decides which records, FLS decides which fields, and the Page Layout decides how it is displayed.

The Salesforce Top-Down Security Evaluation Flow:

Evaluation Order	Layer & Security Mechanism	What It Controls	Consequence if Access Fails at this Gate
1st Gate	Object-Level Security (OLS) Controlled by: Profiles & Permission Sets (CRUD)	Determines if a user can see or interact with an entire object.	Complete denial of access. The user cannot see tabs, related lists, or any records for that object. Downstream layers are not evaluated.
2nd Gate	Record-Level Access Controlled by: OWD, Role Hierarchy, Sharing Rules, Teams, & Manual Sharing	Determines which specific records of that object the user can view or edit.	The user cannot access the specific record. (This layer is only evaluated if OLS passes ).
3rd Gate	Field-Level Security (FLS) Controlled by: Profiles & Permission Sets	Determines which specific fields on that accessed record the user can see or edit.	The specific field is completely hidden or visible-only, regardless of what is configured on the page layout. (Evaluated only if Record Access passes ).
4th Gate	Page Layouts (UI) Controlled by: Page Layout Assignments	Controls how fields, related lists, and buttons are presented visually on the screen.	No security impact. Page layouts are a UI convenience, not a security mechanism. FLS overrides the layout, meaning restricted fields remain hidden even if added to the page.