Salesforce Fundamentals · Topic 2 of 3
Object, Record and Field Access and Sharing Solutions
Salesforce access for app builders: profiles, permission sets, field-level security, org-wide defaults, roles, sharing rules and restriction rules.
- 4 min
- Object access comes from profiles and permission sets; record access from OWD and sharing; field access from field-level security.
- OWD is the most restrictive baseline; sharing tools only open access, except restriction rules.
- Detail records in master-detail inherit sharing from their master.
What it is
Salesforce controls access in three layers. Object access decides whether a user can read, create, edit or delete a type of record at all. Record access decides which individual records they can see. Field access decides which fields on those records they can see or edit.
An app builder uses these layers to meet requirements such as "managers see their team's opportunities" or "only HR sees the salary field".
How it works
Object and field access
| Tool | What it controls |
|---|---|
| Profile | A user's baseline permissions; every user has exactly one |
| Permission set | Extra permissions added to some users without changing their profile |
| Permission set group | A bundle of permission sets assigned together |
| Muting permission set | Removes permissions inside a permission set group |
| Field-level security | Visible and read-only settings for each field, set in profiles and permission sets |
Salesforce recommends giving users a minimal profile and adding access through permission sets. Field-level security is enforced everywhere, including reports, search, list views and the API. Removing a field from a page layout only hides it on that page.
Record access
| Tool | Effect |
|---|---|
| Organization-wide defaults (OWD) | The baseline for each object: Private, Public Read Only or Public Read/Write |
| Role hierarchy | Users see records owned by people below them |
| Sharing rules | Open access to groups or roles, by record owner or by criteria |
| Teams | Account, opportunity and case teams share single records with named users |
| Manual sharing | A record owner shares one record with another user or group |
| Restriction rules | Narrow which records certain users can see, for supported objects |
OWD sets the most restrictive level, and the other tools can only open access further. The exception is restriction rules, which limit the records a user sees even when other settings would allow more.
For custom objects you can turn off Grant Access Using Hierarchies, so managers do not automatically see their team's records. Standard objects always use the hierarchy.
Relationships and sharing
On a master-detail relationship, the detail record has no owner of its own and inherits access from its master. Its OWD is set to Controlled by Parent. On a lookup relationship, each record keeps its own owner and sharing.
Choosing a sharing solution
| Requirement | Solution |
|---|---|
| Nobody sees others' records by default | OWD Private |
| Managers see their reports' records | Role hierarchy |
| The support team sees all accounts in a region | Criteria-based or owner-based sharing rule |
| One colleague helps on one deal | Opportunity team or manual sharing |
| Contractors must not see confidential cases | Restriction rule |
| A user needs to edit a field others only read | Field-level security through a permission set |
A worked example: Invoice__c records contain amounts that only the finance team and each invoice's owner should see. The builder sets the OWD for Invoice__c to Private, creates a public group for finance and adds a sharing rule that shares all invoices with that group. A permission set gives the finance users read and edit access to the object, and field-level security hides the internal margin field from everyone outside finance.
Ask two questions in order. Can the user work with this object at all (profile or permission set)? Which records can they see (OWD and sharing)?
How the exam asks about this
- "Users can open the object but cannot see a colleague's record." Record access: OWD and sharing.
- "The field shows on the layout but one group must not see it." Field-level security.
- "Give a few users an extra permission without new profiles." A permission set.
What to remember for the exam
- Object access comes from profiles and permission sets; record access from OWD and sharing; field access from field-level security.
- OWD is the most restrictive baseline; sharing tools only open access, except restriction rules.
- Detail records in master-detail inherit sharing from their master.
- Field-level security, not the page layout, secures a field.
- Permission sets are the preferred way to add access.
Sharing a record never grants object permissions. If a user lacks read access to the object, a sharing rule shows them nothing.
Common mistakes
Hiding a field by removing it from the layout. Users can still reach it in reports and list views; use field-level security.
Creating a new profile for every small difference. Use permission sets instead.
Expecting a sharing rule to restrict access. Sharing rules only open access; set a stricter OWD instead.
Check yourself
Which setting is the starting point for record access on an object?
The organization-wide default, which sets the most restrictive baseline.
How can a field be hidden from a group of users everywhere in Salesforce?
Remove read access to it with field-level security in their profile or permission set.
Why does a detail record in a master-detail relationship have no owner?
Its access is controlled by its master record, so it inherits the master's sharing.
Topic 2 of 3 in Salesforce Fundamentals
Test yourself on Salesforce Fundamentals
The full Salesforce Platform App Builder question bank has 648 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Salesforce. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.