Sharing rules, org-wide defaults and public groups
OWD, the role hierarchy, owner- and criteria-based sharing rules, public groups and the View All permission on the profile matrix.
Access is built in three layers#
Whether a user can see a record is the combination of three settings: the org-wide default (the floor), the role hierarchy (vertical opening) and sharing rules (horizontal opening). All three live under Setup > Sharing Settings and Setup > Role Hierarchy. Every decision is enforced on the server and cannot be bypassed around the UI.
1. Org-wide defaults (OWD)#
The upper table on the Sharing Settings page sets the floor per object:
| Setting | Meaning |
|---|---|
| Public Read/Write | Everyone in the org sees and edits (the default) |
| Public Read Only | Everyone sees; only the owner and administrators edit |
| Private | Only the owner and administrators see |
The table lists your licensed objects and any custom objects from Object Manager automatically. Records without an owner stay visible to everyone.
2. The role hierarchy#
The role hierarchy is a linear list: the top role is the most privileged and authority narrows as you go down. A role above sees and edits the records owned by the roles below it, even when sharing is Private or the profile permission is Own. The reverse never applies. A new role is added at the top of the list and positioned with the arrow buttons. Roles are assigned to people in the Hierarchy column of the Users tab; a user with no role gets no benefit from the hierarchy.
3. Sharing rules#
A sharing rule re-opens access on an object whose OWD is Private or Public Read Only. Create one with + New Rule; it has five parts:
- A rule name and an object.
- Rule type: Based on record owner or Based on criteria.
- Which records: an owner-based rule picks a source (All records, a role, a role and subordinates, a public group or a queue). A criteria-based rule takes conditions and all of them must hold (City equals Istanbul, for example).
- Share with: a role, a role and subordinates, a group or a single user.
- Access level: Read Only or Read/Write.
Every rule has an active toggle. If the object's OWD is Public Read/Write, the rule is badged as ineffective in the list and the rule window warns you: everyone already sees the records, so the rule changes nothing.
Public groups#
A group is a set of users and roles you can use as the source or the target of a sharing rule. Create one with + New Group on the Public Groups card of the same page, adding members individually and, if useful, whole roles. The difference from a queue matters: a group cannot own records, it is only an access target. Deleting a group that rules depend on raises a warning; if you go ahead, those rules become ineffective.
View All and Modify All on the profile matrix#
In the object permission table on Setup > Profiles, the Read and Edit columns each offer four levels:
- All: follows the sharing setting (OWD).
- View All and Modify All: bypass sharing settings and the role hierarchy, seeing or editing every record of that object.
- Own: only the records the user owns.
- None: the object is entirely invisible to that user.
Modify All can only be chosen when Read is set to View All. These two levels exist for auditors, finance or operations roles that need full visibility on a single object: they grant wide access without handing out an administrator profile.
Do not confuse it with list view sharing#
The Sharing window on list screens (Only me / The whole organization / Specific public groups) shares the view itself: its columns, filters and sort order. It grants no record access. Even when a view is shared with the entire org, each user still sees only the records they are entitled to see in it. See List views for views, and Users, profiles and the role hierarchy for the user and profile design.