2.1 Object-Level & Field-Level Security

2.1 Object-Level & Field-Level Security

Salesforce implements a layered security model designed to provide fine-grained control over what users can view, edit, and manage. At the foundation of this architecture are two essential layers: Object-Level Security and Field-Level Security (FLS). Together, they establish what data structures (tables and columns) a user can access before record-level sharing rules ever evaluate which specific rows the user is permitted to open.

Understanding how Profiles, Permission Sets, Permission Set Groups, and Field-Level Security interact is one of the highest-yield domains on the Platform App Builder examination. A solid grasp of these controls ensures you can configure least-privilege access models without accumulating technical debt.

---

The Authorization Model: Tables vs. Columns vs. Rows

To build a robust security model, you must distinguish between the three distinct layers of data security in Salesforce:

1. Object-Level Security (Tables): Controls whether a user can access an object type at all (e.g., Accounts, Opportunities, or a custom Certification__c object) and what basic actions they can perform on it.
2. Field-Level Security (Columns): Controls whether a user can view or edit a specific field on that object (e.g., hiding Salary__c or Social_Security_Number__c while allowing access to the rest of the record).
3. Record-Level Security (Rows): Controls which individual record rows a user can see, edit, or delete once they possess object and field permissions.

---

Profiles vs. Permission Sets vs. Permission Set Groups

Managing user authorization historically relied heavily on Profiles. Modern Salesforce architecture, however, enforces a least-privilege model where Profiles are stripped to their bare operational minimum and all functional permissions are layered additively using Permission Sets and Permission Set Groups.

Profiles: The Baseline Identity

Every user in Salesforce must have exactly one profile assigned to their user record. The profile determines:

• Assigned Page Layouts: Which standard page layout a user sees for each record type when Dynamic Forms is not fully adopted.
• Assigned Apps and Tabs: Which applications appear in the App Launcher and which tabs are visible by default.
• Login Hours and IP Ranges: When and from which network IP addresses the user is permitted to log in.
• Record Type Assignments: Which record types are available to the user when creating new records.
• Baseline Object CRED: Baseline object permissions and Field-Level Security.

Because users can have only one profile, creating new profiles for minor permission differences leads to "profile explosion"—an unmaintainable configuration where an organization accumulates hundreds of near-identical profiles.

Permission Sets: Additive Modular Grants

A Permission Set is a collection of settings and permissions that extends user access without altering profiles. Users can be assigned zero, one, or dozens of permission sets. Permission sets are purely additive: they can grant additional permissions, but they can never revoke access granted by a user's profile or another permission set.

Permission sets are optimal for:

• Granting specialized permissions to a subset of users across different departments (e.g., granting "Import Leads" to two sales reps and one marketing specialist).
• Authorizing access to custom objects and third-party AppExchange packages.
• Exposing sensitive fields via Field-Level Security to designated auditors.

Permission Set Groups: Enterprise Packaging

A Permission Set Group (PSG) bundles multiple permission sets together into a single administrative unit. Instead of manually assigning five separate permission sets to every new customer support agent, an administrator assigns the single "Customer Support Specialist" Permission Set Group.

---

Object Permissions: The CRED Matrix and Administrative Overrides

Object permissions dictate the basic operations a user can execute on records of a given object. These are commonly referred to as CRED permissions:

• Create: Allows the user to create new records of the object.
• Read: Allows the user to view records of the object (subject to record-level sharing).
• Edit: Allows the user to modify existing records of the object.
• Delete: Allows the user to delete records of the object.

In addition to CRED, Salesforce provides two administrative super-permissions at the object level:

• View All: Grants the user Read access to all records of that object, completely bypassing Organization-Wide Defaults, the role hierarchy, and sharing rules.
• Modify All: Grants the user full Read, Edit, Delete, Transfer, and Approval permissions on all records of that object, completely overriding record ownership and sharing rules.

---

Field-Level Security (FLS) vs. Page Layouts

One of the most frequently tested distinctions on the Platform App Builder exam is the difference between hiding a field using Field-Level Security versus removing it from a Page Layout.

Field-Level Security and Execution Context

Field-Level Security controls whether a field is Visible (Read) or Read-Only (Edit) for a given profile or permission set. When a field is hidden via FLS:

• It disappears from record detail pages and Dynamic Forms.
• It is omitted from reports run as that user. A dashboard running as a more privileged specified user can expose aggregate data, so review its running user and folder audience.
• It cannot be discovered or viewed in Global Search or list views.
• It is protected in user-context API operations such as Data Loader. Apex normally runs in system mode and must enforce CRUD/FLS explicitly; record-triggered Flow also runs in system context. A visible formula can expose a hidden source field's value, so review derived fields too.

If a field is configured as Read-Only via FLS, user-context interfaces prevent edits. System-context automation and privileged integrations require their own access design.

Page Layouts: Superficial UI Organization

Page layouts govern only the presentation layer of standard detail and edit pages. Removing a field from a page layout or marking it "Read-Only" on the page layout does not secure the field:

• Users can still query and extract the field using the API or Data Loader.
• Users can view and summarize the field in Reports and Dashboards.
• Users can search for field values using Global Search.
• If the field is present on a List View, users with object edit permissions can often modify it using inline editing unless FLS is enforced.

---

Muting Permission Sets in Permission Set Groups

When using Permission Set Groups, an organization might want to assign a group to a cohort of users who need almost all of the group's permissions, but must have one specific capability withheld. Rather than decomposing the entire group into smaller permission sets, Salesforce provides Muting Permission Sets.

A Muting Permission Set is added directly to a Permission Set Group. It selectively disables (mutes) individual permissions within that group:

• It affects only users assigned to that specific Permission Set Group.
• It does not modify the underlying individual permission sets.
• If a user is directly assigned an individual permission set outside the group, the muted permission in the group does not mute their standalone permission.

[Permission Set Group: Sales Operations]
  ├── [Permission Set A: Account Management (Create, Read, Edit, Delete)]
  ├── [Permission Set B: Contract Operations (Create, Read, Edit, Delete)]
  └── [Muting Permission Set: Mutes Delete on Contracts]
Result for assigned users: Full Account access; Contract Create, Read, Edit; Contract Delete is MUTED.

---

Session-Based Permission Sets

A Session-Based Permission Set activates functional access only during an active, authenticated user session that satisfies a specific condition. For example:

• Authorizing a user to access sensitive credit card tokenization fields only while they are connected through a corporate VPN or verified with multi-factor authentication (MFA).
• Temporarily elevating a customer support supervisor's object permissions to delete duplicate records while actively executing a guided Screen Flow.

Session-based permission sets can be activated declaratively using the Activate Session-Based Permission Set core action inside a Salesforce Flow, or programmatically via the SessionPermSetActivation SOAP/REST API object.