Top Salesforce Security Interview Questions & Answers (Modern Architecture)

If you are stepping into a Salesforce Administrator or Developer interview, you can guarantee that the security model will be a major topic. Salesforce data security is essentially a puzzle with two distinct halves: controlling what a user can do with an object, and controlling which specific records they are allowed to see. If you don't connect these dots perfectly, you risk exposing sensitive client data.

In plain words: The Salesforce security model operates on two main tiers. Object-Level Security (managed via Profiles and Permission Sets) determines if a user can see or edit an entire table of data, like "Accounts." Record-Level Security (managed via OWD, Role Hierarchies, and Sharing Rules) determines which specific rows in that table a user can actually look at, like "Acme Corp vs. Stark Industries."

Key Points Summary

• The era of using Profiles to manage all user permissions is over. Modern architecture relies on Permission Sets and Permission Set Groups.
• Object permissions (CRUD) act as your overarching master key. If a user lacks Read access to an object, no amount of record sharing will make those records visible.
• Organization-Wide Defaults (OWD) are the only mechanism that locks data down. Everything else (Role Hierarchy, Sharing Rules) opens data up.
• Salesforce recently introduced Restriction Rules, giving admins the ability to finally block access to specific records after sharing rules have opened them.

Core Security Interview Questions & Answers

Q1. What is a Profile in Salesforce, and how is its role changing?

A Profile is a mandatory baseline assigned to every user upon creation. Historically, it handled everything: object permissions (Create, Read, Edit, Delete), field-level security, and system setups. Today, Salesforce best practice dictates using Profiles strictly for baseline configurations—like Login IP Ranges, Login Hours, and Default Page Layouts—while moving all actual data permissions to Permission Sets.

Q2. What are Permission Sets and Permission Set Groups?

A Permission Set is an add-on that grants extra access a user didn't get from their base Profile. Because users can only have one Profile but unlimited Permission Sets, this approach makes security highly flexible. A Permission Set Group bundles multiple Permission Sets together, allowing admins to assign a single "Sales Rep" group rather than tracking 15 individual permission sets.

Modern Architecture Example: Assign all users the standard "Minimum Access - Salesforce" Profile. If John is a Sales Manager, assign him the "Sales Basics" Permission Set Group, plus an individual "Manager Approvals" Permission Set. This eliminates the need for dozens of cloned custom profiles.

Q3. What are Organization-Wide Defaults (OWD)?

Organization-Wide Defaults (OWD) establish the most restrictive baseline access for records in your system. It answers the question: "If I do not own this record, what can I do with it?"

The standard OWD settings are:

• Private: You can only see the records you own. (Others are hidden).
• Public Read-Only: Everyone can search and view all records, but only the owner can edit them.
• Public Read/Write: Everyone can view and edit everything. (Ownership still matters for deletion and reporting).
• Controlled by Parent: Exclusively used for Master-Detail relationships. The access level of the child record is entirely dictated by who can see the parent record.

Q4. How does the Role Hierarchy work?

The Role Hierarchy visually represents your company's management structure. When enabled, it ensures that managers automatically inherit access to all records owned by the users directly below them in the tree. This grants vertical access.

Q5. What are Sharing Rules?

If your OWD is locked down to Private, you use Sharing Rules to punch specific holes in that security wall. Sharing Rules grant automatic exceptions to groups of users based on either who owns the record or specific criteria on the record itself. This grants horizontal access across different teams.

Q6. What is the difference between Sharing Rules and Restriction Rules?

This is a modern interview question designed to test if your knowledge is up to date. Sharing Rules can only grant access. They never hide data. Restriction Rules do the exact opposite. They act as a filter applied at the end of the security funnel to block access to specific records (like highly confidential HR data), even if OWD or Sharing Rules previously opened them up.

Q7. What is Field-Level Security (FLS) vs. Page Layouts?

Removing a field from a Page Layout only hides it from the standard UI screen; users can still find the data via Reports, List Views, or API queries. Field-Level Security (FLS) restricts access at the database level. If a user's Profile or Permission Set denies FLS to the "Social Security Number" field, they cannot see or query it anywhere in the system, regardless of the Page Layout.

Q8. Practical Scenario: User A and User B have the same job title. User A needs Read access to Opportunities, but User B needs Read/Write access. How do you design this?

Never create two separate Profiles for this! First, assign both users to a single "Sales Base" Profile that grants strictly Read-Only access to the Opportunity object. Then, create a "Sales Edit Opportunities" Permission Set that grants Edit access on the object. Finally, assign that Permission Set exclusively to User B.

Common Developer Pitfalls:

• "OWD Opens Data": A huge misconception. OWD is the lock on the door. It is the only feature that restricts record access (excluding the newer Restriction Rules).
• Confusing Object vs. Record Security: You can create a Sharing Rule giving someone access to a specific Account record, but if their Permission Set lacks "Read" access on the Account object, they will never see it. Object security always overrides record security.

Security Golden Rule: Lock down your Organization-Wide Defaults to the most restrictive level required by your business, and then selectively use Hierarchies, Sharing Rules, and Permission Sets to open data up.

360 Security Summary Card

• Object-Level (What can you do?): Profiles, Permission Sets, Permission Set Groups
• Field-Level (What columns can you see?): Field-Level Security (FLS)
• Record-Level Baseline (Lock it down): Organization-Wide Defaults (OWD)
• Record-Level Expansion (Open it up): Role Hierarchy, Sharing Rules, Manual Sharing, Apex Managed Sharing
• Record-Level Restriction (Hide it again): Restriction Rules, Scoping Rules