Study guide
2.1 Object-Level & Field-Level Security
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
2.1 Object-Level & Field-Level Security
Key Takeaways Explain This Topic AI
Every user is assigned exactly one Profile that defines base object CRED permissions, page layout assignments, and login IP/hour restrictions.
Permission Sets and Permission Set Groups provide modular, additive permissions without requiring profile duplication or sprawl.
Object permissions govern access to entire tables via CRED (Create, Read, Edit, Delete), augmented by View All and Modify All administrative overrides.
Field-Level Security (FLS) controls field visibility and editability in user-context interfaces, including standard UI, reports, and API tools. System-context Apex/Flow and derived formulas require separate security review.
Muting Permission Sets within Permission Set Groups allow architects to selectively withdraw permissions inherited from bundled sets without modifying component permission sets.
Last updated: October 2026
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:
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.
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).
Record-Level Security (Rows) : Controls which individual record rows a user can see, edit, or delete once they possess object and field permissions.
Important
Security evaluation is strictly hierarchical. If a user lacks Read permission on an object at the object level, they cannot view any records of that object, even if they own the records, even if the Organization-Wide Default is Public Read/Write, and even if an administrator manually shares a record with them.
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.
- Attribute Profile Permission Set Permission Set Group
- Multiplicity Exactly 1 per user 0 to many per user 0 to many per user
- Permission Nature Baseline configuration Additive functional grant Additive bundled package
Structural Contents Page layouts, login hours, IP ranges, CRED, FLS CRED, FLS, system permissions, app/tab access Multiple permission sets bundled as one
Primary Architectural Role Defines user license and core platform identity Modular functional entitlement Role-based entitlement packaging
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.
Note
"View All Data" (VAD) and "Modify All Data" (MAD) are system-level permissions that apply "View All" or "Modify All" across every single object in the entire Salesforce organization. In contrast, "View All" and "Modify All" on an individual object apply only to that specific object.
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.
Tip
Whenever an exam scenario mentions compliance, privacy, or protecting sensitive financial or HR data (such as executive salaries or social security numbers), Field-Level Security is the right field-authorization layer , together with checks on privileged execution and derived outputs. Page layouts must never be relied upon for data confidentiality.
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.