Lesson 10 of 18 · 5–7 minutes
Profiles, Permission Sets & Object Access
Security starts with the objects you modeled. Establish allowed operations before troubleshooting fields or individual records.
Learning sequence · data model first, security layers next
- What CRM and Salesforce Do
- The Salesforce Ecosystem and Major Clouds
- Org, App, Object, Field, and Record
- Standard and Custom Objects
- Common Standard Objects
- Field Types and Data Quality
- Objects, Fields & Records
- Lookup vs Master-Detail
- Many-to-Many Relationships and Junction Objects
- Profiles, Permission Sets & Object Access
- Field-Level Security
- OWD and Least-Privilege Record Access
- Opening Access: Role Hierarchy, Sharing Rules, Public Groups & Apex Sharing
- Apex First Steps
- Variables and Collections
- SOQL and DML Basics
- Why Asynchronous Apex Exists
- REST Callout Introduction
Your focus
Prepare for Senior / Lead Roles
CHECKPOINT · Checkpoint • Design • Troubleshoot
- Review permission-set governance, license constraints and broad-access exceptions.
Learning objective
Separate object permissions from record sharing and assign task-based permissions.
Before you start
Data entities and relationships; how ownership may be inherited.
Real-world scenario
Temporary onboarding specialists need to read and update Applications for six weeks. Grant those operations through a task permission set instead of cloning several profiles. Record access and sensitive-field access still need separate decisions.
The concept
A user has one profile and can receive additional permission sets or permission set groups. Object permissions specify Create, Read, Edit and Delete. Use a minimal profile and task-focused permission sets where practical. Grants are additive across assignments: removing one permission set does not revoke a permission granted elsewhere. Profiles and permission sets do not by themselves describe the entire record-sharing model. Broad permissions such as View All Records and Modify All Records can bypass ordinary sharing restrictions for an object.
Write an operation matrix first: specialist = Read/Edit, auditor = Read. Check license compatibility, avoid unnecessary Delete, and plan assignment removal. The next lesson adds field permissions; do not treat the object grant as the end of the design.
Permission assignments grant operations; the next lessons add field and record checks.
1.User
Onboarding specialist.
2.Profile + assigned permission sets
Combine effective grants.
3.Object access
Application Read/Edit; no unnecessary Delete.
- User connects to Profile + assigned permission sets: receives permissions
- Profile + assigned permission sets connects to Object access: determines allowed object operations
Common mistake
Opening OWD because a user lacks object Read. Sharing cannot repair a missing object permission. Conversely, object Edit does not guarantee edit access to every record.
Interview angle
“A user has object Edit but cannot edit this record—why?” Check field permissions and record access as separate layers before granting a broad override.
Pause and apply
List the minimum operations for a temporary reviewer and a permanent onboarding manager. Which grant would you remove when the review ends?
Official references
- Trailhead: Control Access to Objects (opens in a new tab)
- Trailhead: Control Access to Records (opens in a new tab)
Reviewed 2026-09-22. Examples are illustrative; no code is executed here.
Key takeaways
- Object CRUD answers what actions are allowed on a type of data.
- Permission sets add access; they are not general deny rules.
- Fields and records need their own checks.
Practice next
After the next lesson, combine object and field permissions in a temporary-access design.
Temporary Project Access Without Profile SprawlReading these lessons does not yet save completion. Challenge results continue to provide assessment evidence.