Sharing Settings
Sharing Settings is a Setup page in Salesforce where administrators define the organization-wide default (OWD) access level for each object and create the sharing rules that extend access beyond those defaults.
Definition
Sharing Settings is a Setup page in Salesforce where administrators define the organization-wide default (OWD) access level for each object and create the sharing rules that extend access beyond those defaults. The OWD section sets the baseline visibility every user has to records they do not own, choosing from levels like Private, Public Read Only, and Public Read/Write per object.
The page works as the floor of the record-level security model. Role hierarchies, sharing rules, manual shares, and Apex sharing all stack on top to grant more access. None of those tools can take access below what the OWD sets, so Sharing Settings is where you decide how locked down each object starts.
How OWD and sharing rules combine on one page
What the Sharing Settings page actually contains
The page opens in Setup under Quick Find, Sharing Settings. It has two main regions. The top region is Organization-Wide Defaults, a table listing every object with a Default Internal Access column and a Default External Access column. The bottom region holds the sharing rules grouped by object, plus the Manage Sharing Settings area for deferred recalculation on large orgs. From this single page an admin sets the baseline for accounts, contacts, opportunities, cases, leads, custom objects, and more. Each row also reflects the Grant Access Using Hierarchies checkbox, which controls whether people above a record owner in the role hierarchy automatically inherit access. For standard objects that box is locked on. For custom objects you can clear it, which stops managers from seeing subordinate records through the hierarchy alone. Treat the page as the security contract for the org: the OWD column is the promise about who sees what, and the sharing rules below are the documented exceptions to that promise.
The access levels you can choose
Most objects offer four core levels. Private means only the owner, users above them in the role hierarchy, and anyone granted access through sharing can view or edit the record. Public Read Only lets everyone view and report on records but limits edits to owners and their managers. Public Read/Write lets everyone view, edit, and report on all records of that object. Controlled by Parent ties a child record's access to its parent, common for objects in a master-detail relationship. Some objects add special levels. Leads and Cases offer Public Read/Write/Transfer, which also allows changing ownership. Campaigns offer Public Full Access, allowing view, edit, transfer, delete, and report. Price Books use Use and View Only rather than the standard set. Activities support Private and Controlled by Parent, and Calendars range from Hide Details up to Full Access. User records can be Private or Public Read Only, which decides whether people can see each other in lookups and the user list.
Internal access versus external access
Salesforce splits the default into two columns so you can hold external users to a stricter standard than employees. Default Internal Access applies to your licensed internal users. Default External Access applies to authenticated external users such as Experience Cloud (community) members and legacy portal users. The platform enforces one firm rule: the default external access must be equal to or more restrictive than the default internal access. You cannot give the outside world more visibility than your own staff. This separation matters most when you stand up a customer or partner site. You might keep internal access at Public Read Only for accounts while setting external access to Private, so portal users see only the records explicitly shared with them. Orgs created in Spring 2020 or later default external access to Private on every object. Guest users sit outside this model entirely. Their org-wide default is Private for all objects and cannot be changed, so unauthenticated traffic starts with no record visibility at all.
Why changing OWD on a live org is expensive
Tightening or loosening an OWD is not a quiet save. When you change a default, Salesforce recalculates sharing for every affected record so the share table matches the new rule. On a small org this finishes fast. On an org with millions of records, recalculation runs asynchronously in the background and can take hours, with an email sent to you when it completes. There is an important asymmetry here. Opening access wider, for example moving from Private to Public Read Only, takes effect almost immediately. Restricting access, moving from public to Private, only finishes once the recalculation completes. Because of this cost, teams invest real effort in getting OWD right before an object holds production data. The page also enforces dependencies. If Account is set to Private, then Opportunity and Case must also be Private, since those children inherit account context. A few objects cannot be changed at all, such as user provisioning requests, which stay Private permanently.
A worked example: a sales org
Picture a sales team that wants reps to own their own opportunities without seeing each other's deals, while sales operations needs to report across everything. On the Sharing Settings page you set Account and Opportunity to Private. That hides records by owner. Reps now see only their accounts and the opportunities under them, plus anything their managers own above them in the role hierarchy. Sales operations still needs visibility. Rather than loosening the OWD, you scroll to the sharing rules section and create an owner-based rule that shares all opportunities owned by the Sales Reps role with the Sales Operations public group, granting Read access. A second criteria-based rule could share opportunities where Stage equals Closed Won with a Finance group. The baseline stays Private, so the data is locked down by default, and each business need that requires wider access becomes a visible, named rule. This is the intended pattern: restrict with OWD, then extend deliberately with rules instead of opening the floor for everyone.
Where Sharing Settings fits in the security stack
Record-level access is only one layer. Profiles and permission sets decide object-level and field-level access, answering whether a user can touch the object or field at all. Sharing Settings then decides which specific records that user sees among the ones they are allowed to touch. The two layers gate each other. A Public Read/Write OWD means nothing if the user's profile lacks Read on the object, and a generous profile still respects a Private OWD for records the user does not own. Below the OWD, the tools that grant more access form a clear order. The role hierarchy gives managers their subordinates' records. Sharing rules open access to roles, groups, or territories by ownership or by record criteria. Manual sharing handles one-off cases through the Share button. Apex managed sharing covers programmatic needs that declarative rules cannot express. Reading the Sharing Settings page top to bottom shows the whole record model: the OWD floor first, then every documented exception that lifts particular users above it.
How to set an organization-wide default
Set the organization-wide default for an object and confirm the hierarchy behaviour. Do this before the object holds large volumes of production data, because later changes trigger a sharing recalculation.
- Open Sharing Settings
From Setup, type Sharing Settings in the Quick Find box and select Sharing Settings. The Organization-Wide Defaults table lists every object with its current internal and external access.
- Edit the defaults
Click Edit in the Organization-Wide Defaults area. For each object choose a Default Internal Access and a Default External Access. Remember external access must be equal to or more restrictive than internal access.
- Set hierarchy access for custom objects
For custom objects, decide whether to keep Grant Access Using Hierarchies selected. Leaving it on lets managers inherit subordinate records. Clearing it limits hierarchy-based access for that object.
- Save and wait for recalculation
Click Save. If you restricted access on a populated object, sharing recalculates in the background and you receive an email when it finishes. Verify access with a test user afterward.
Only the owner, users above them in the role hierarchy, and people granted access through sharing can see the record.
Everyone can view and report on records, but only owners and their managers can edit them.
Everyone can view, edit, and report on all records of the object.
Access to the record follows the user's access to its parent record, used with master-detail relationships.
- Restricting access on a large object runs an asynchronous recalculation that can take hours; widening access applies almost immediately.
- If Account is Private, Opportunity and Case must also be Private because they inherit account context.
- Default external access cannot exceed default internal access, and guest users are always Private with no override.
- You cannot switch a custom object from private to public if Apex code references its sharing entries.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Sharing Settings.
Hands-on resources to go deeper on Sharing Settings.
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. Why is understanding Sharing Settings important for Salesforce admins?
Q2. What is the primary benefit of Sharing Settings for Salesforce administrators?
Q3. Can a Salesforce admin configure Sharing Settings without writing code?
Discussion
Loading discussion…