Private Sharing
Private sharing is a Salesforce organization-wide default (OWD) access level.
Definition
Private sharing is a Salesforce organization-wide default (OWD) access level. When an object is set to Private, only the record owner, users above that owner in the role hierarchy, Salesforce admins, and users granted access through sharing can view, edit, or report on those records.
Private is the most restrictive OWD setting. It locks records down to their owners as a baseline, then lets you open access back up deliberately through role hierarchy, sharing rules, manual sharing, and other features.
How Private fits the layered sharing model
What "Private" actually means per object
Private is one of several organization-wide default values you choose per object under Setup. Salesforce defines it precisely. Only the record owner, users above that owner in the role hierarchy, system administrators, and anyone granted access through a sharing mechanism can view, edit, and report on the record. Everyone else sees nothing for records they do not own. You set Private separately for each standard and custom object, so Accounts can be Private while Cases stay Public Read/Write. Some objects have their own variations. Activities support Private or Controlled by Parent. User records support Private or Public Read Only. Because Private is the floor, no role hierarchy entry or sharing rule can ever take access below it. Those features only grant access on top of the baseline. That one-directional rule is why architects describe OWD as the most restricted access the least-privileged user should have. Start tight with Private, then widen access where the business genuinely needs it.
Private as the baseline, not the whole story
Private rarely works alone. It is the bottom layer of a stacked model, and Salesforce evaluates every layer to compute a user's effective access. A user receives the highest access any single mechanism grants, never the lowest. So a record owned by someone else, on a Private object, can still be visible to you if a sharing rule, your manager position, a team membership, or a manual share reaches it. The layers above Private are the role hierarchy, sharing rules, manual sharing, teams and queues, and Apex managed sharing. Each one is additive. None of them can claw access back. This is what makes Private safe to use as a starting point. You commit to a locked default, then grant exactly the exceptions you intend. If you instead start with Public Read/Write, you have no way to make a subset of records private again, because sharing features cannot restrict. That asymmetry is the single most important reason to reach for Private first when data is sensitive.
Opening access back up above a Private floor
Once an object is Private, several tools widen access in controlled ways. The role hierarchy, when Grant Access Using Hierarchies is on, gives managers access to records owned by people below them. Sharing rules grant access to groups, roles, or roles and subordinates based on record ownership or field criteria. They are the standard way to say "everyone in Sales can see each other's Opportunities" without going public. Manual sharing lets a record owner, or someone above them, share one specific record with one user, role, or group. Teams (account teams, opportunity teams, case teams) grant access to named collaborators on a record. Apex managed sharing handles programmatic cases where declarative rules are not flexible enough. The pattern across all of them is the same. Private decides who is locked out by default, and each of these decides who gets let back in. Designing access well means planning these grants up front, not bolting them on after users complain they cannot see their own team's data.
Internal versus external Private defaults
Salesforce splits organization-wide defaults into internal and external columns. The internal default governs employees and standard Salesforce users. The external default governs Experience Cloud site users, guest users, and other external authenticated users like high-volume community accounts. You can set an object to Public Read Only internally while keeping it Private externally, which is a very common posture for community deployments. A hard rule applies. The external default can never be more permissive than the internal one. If internal access is Private, external cannot be Public. This stops a misconfiguration from exposing internal records to external audiences. When you first enable external organization-wide defaults, Salesforce sets external values to match your existing model so nothing changes unexpectedly. For most security-conscious orgs, the safe external baseline is Private, then specific sharing sets and sharing rules grant community users exactly the records they need. Treating external Private as the default closes a category of accidental data exposure that is hard to detect after the fact.
What happens when you change a default to Private
Changing an OWD is not instant when you tighten it. Increasing access, such as moving from Private to Public Read Only, takes effect right away. Decreasing access, such as moving Public Read/Write down to Private, kicks off sharing recalculation. Salesforce reprocesses the sharing tables for every affected record, and in large orgs that can take a while. You get an email when the recalculation finishes. There are also guardrails on when you can change a default at all. If Apex code references sharing entries for a custom object, Salesforce can block changes to that object's default. Going more restrictive can remove access some users currently rely on, so plan the move during a low-traffic window and communicate it. Conversely, when you loosen a default, redundant manual shares and sharing-rule grants are cleaned up asynchronously because they are no longer needed. Always test a Private change in a sandbox first, since the access loss for non-owners is immediate from the user's point of view once recalculation lands.
When to choose Private (and when not to)
Private is the right default when records belong to an individual and should not be broadly visible. Recruiting candidates, financial deals, HR cases, and B2C customer records are typical examples. Regulated data almost always starts Private, because compliance reviewers want to see a locked baseline with documented exceptions rather than open access with carve-outs. Private is the wrong default when collaboration is the point and the data is not sensitive. A shared knowledge object, an internal reference catalog, or a company-wide announcement record collaborates better as Public Read Only or Public Read/Write. Over-using Private creates a different problem. Users file tickets because they cannot see records they reasonably expect to, and admins respond with a sprawl of sharing rules that becomes hard to audit. The healthy pattern is to set Private only where confidentiality demands it, then grant the minimum access that lets people do their jobs. That keeps your sharing configuration both secure and explainable.
Set an object's default to Private
You set Private at the organization-wide default level, per object, in Sharing Settings. This is an admin action that changes the baseline access for everyone who does not own the record. Test in a sandbox first, because tightening a default removes access from non-owners once recalculation completes.
- Open Sharing Settings
From Setup, type Sharing Settings in the Quick Find box and select it. This page lists the organization-wide defaults for every standard and custom object in one grid.
- Edit the Organization-Wide Defaults area
Click Edit in the Organization-Wide Defaults section. You will see a Default Internal Access column, and a Default External Access column if external defaults are enabled.
- Set the object to Private
Find the object you want to lock down and choose Private in its Default Internal Access dropdown. Set the external default to Private too unless the business needs external users to see more.
- Review Grant Access Using Hierarchies
Decide whether managers should automatically see records owned by people below them. For custom objects you can turn this off; for standard objects it stays on. Leave it on unless you have a specific reason not to.
- Save and wait for recalculation
Click Save. If you tightened access, Salesforce starts sharing recalculation and emails you when it finishes. Verify with a non-owner test user that records are now hidden as expected.
The baseline for internal users. Set to Private so only owners and their management chain see the records by default.
The baseline for Experience Cloud and other external users. Cannot be more permissive than the internal value; Private is the safe choice.
Controls whether the role hierarchy opens access upward. Disable only on custom objects where managers genuinely should not inherit subordinate records.
- Tightening a default to Private triggers sharing recalculation that can take time in large orgs; the access loss for non-owners is immediate once it completes.
- The external default can never be set higher than the internal default, so you may need to lower internal access first.
- If Apex code references sharing for a custom object, Salesforce can block changes to that object's organization-wide default.
- Private only sets the floor. Forgetting to add sharing rules or hierarchy access afterward is the usual cause of "I cannot see my team's records" tickets.
Prefer this walkthrough as its own page? How to Private Sharing in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Organization-Wide Sharing DefaultsSalesforce
- Organization-Wide Default Access SettingsSalesforce
Straight from the source - Salesforce's reference material on Private Sharing.
Hands-on resources to go deeper on Private Sharing.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does Private Sharing mean for a file or post in Salesforce Chatter?
Q2. When is Private Sharing the appropriate choice in Chatter?
Q3. How does Private Sharing contrast with a public Chatter post?
Discussion
Loading discussion…