Two checks, both must pass
Whether a user can work with a specific record is decided by two independent checks: their security profile must allow the operation on the entity, and record-level security must allow it on that record. A profile grant without record access filters the record out of lists and refuses it on open; record access without a profile grant is refused outright. This page explains the record half: ownership, the entity's sharing policy, and the ways access to individual records is granted.
- 1
Entity and Ownership: a User Owned policy filters records by owner; Organization Owned skips record filtering entirely.
- 2
Internal Access and External Access are the defaults for records a user does not own — Private, Read Only or Read Write — set separately for staff and portal users.
- 3
Hierarchy Access, Manual Share and Team Access switch on the three additive paths: role roll-up, per-record shares, and shares aimed at teams.
- 4
A rule's Type and Effect say what it does: an AccessGrant with GrantRead widens reading for its audience; an AccessFilter narrows what is visible.
- 5
Audience, Priority and Enabled control who the rule applies to and whether it participates at all; disabled rules are ignored.
- 6
Edit Policy changes the defaults and switches; New Rule adds a grant or filter rule to this entity.
The sharing-policy detail (Setup → Access Control → Policies → open a policy) shows everything the runtime uses for one entity: the ownership model, the default access for internal and external users, whether hierarchy, manual sharing and team access are switched on, and the policy's rules.
Ownership
Every record carries an owner, defaulting to its creator. Ownership is the baseline of record access: on a user-owned entity, owners can always work with their own records within their profile's grants. Ownership is also what the role hierarchy rolls up — where the policy enables hierarchy access, users read (and, for write operations, edit) records owned by users whose roles sit below theirs.
Ownership is transferred by changing the record's owner, which needs Update on the record. The grant matrix also lists an Assign operation; the runtime does not currently apply a separate Assign check when the owner changes, so do not rely on withholding Assign to lock ownership.
The sharing policy
Each entity has at most one sharing policy, managed under Setup → Access Control → Policies. The list shows every policy with its entity, ownership model and status; open one to see and edit its settings (Edit Policy) or add rules (New Rule).
| Policy setting | What it decides |
|---|---|
| Entity | The entity this policy governs — one policy per entity. |
| Ownership Model | Organization Owned — no record filtering at all; only the profile check applies. User Owned — records are filtered by owner plus the mechanisms below. Team Owned is offered in the form but the runtime currently evaluates it exactly like User Owned. |
| Internal Default Access | What internal (staff) users get on records they do not own: Private, Read Only or Read Write. |
| External Default Access | The same, set separately for external users (portal and partner logins). |
| Grant Access Using Hierarchy | Whether users reach records owned by people in roles below theirs in the role tree. |
| Allow Manual Share | Whether per-record shares are honoured for this entity. |
| Allow Team Access | Whether the user's team memberships count when shares are resolved. |
| Active | An inactive policy is ignored, which drops the entity back to the no-policy behaviour described below. |
Two defaults matter. Platform entities ship with a DefaultSharing<Entity> policy that is user-owned with Read Only defaults for both audiences and hierarchy, manual share and team access enabled — everyone reads everything; writing needs ownership, hierarchy or an elevated grant. Entities you create get no policy, and without one the runtime treats the entity as user-owned and Private for both audiences with hierarchy, sharing and team access off — only owners and View All / Modify All holders see records. If a new custom entity seems invisible to everyone but its creators, that is why: create its policy.
How record access composes
A user can read a record when any one of these holds:
- the entity's policy is Organization Owned;
- one of their profiles carries View All for the entity;
- the policy's default access for their audience is Read Only or Read Write;
- they own the record;
- hierarchy access is on and the record's owner sits in a role below one of theirs;
- an enabled Access Grant rule with effect Grant Read matches the record for their audience (see the rules section below);
- manual sharing is on and the record is shared to them — directly, to a role, team or business unit they resolve to, or to all internal or all external users.
Write (update and delete) access is narrower: it comes from Organization Owned, Modify All, a Read Write default, ownership, hierarchy, a share whose access includes the requested operation, or a matching Grant Write rule. Modify All is the one grant that skips record filtering entirely for update and delete.
Record-level grants are additive; a sharing policy has no deny effect. The only subtractive element is an Access Filter rule with effect Filter Visible Records, whose predicate is ANDed onto the final query after every grant has been evaluated — see restriction rules. Composition with profiles works one way only: record-level grants never widen entity access (sharing a record with a user who has no Read on the entity achieves nothing), while View All and Modify All step around record-level scoping.
Two details are easy to miss:
- Team access resolves the user's teams (direct membership and team-member rows) only when the policy enables it; a share aimed at a team is invisible with team access off.
- Business-unit shares match through the user's roles — a user belongs to a business unit through the roles assigned to them, not through a field on the user.
Rules on a policy
Rules are listed on the policy detail and added with New Rule. Each rule has a Rule Type, an Effect, Applies To Audience (All, Internal or External), Applies To Operations (Read, Update, Delete or Share — a rule participates only when its operations cover every operation the request needs), a Priority, an Enabled switch, and then its expressions and targets on the rule's own detail page.
| Rule type | Effect | What it does |
|---|---|---|
| Access Grant | Grant Read / Grant Write / Grant Share | Widens access: records matching the rule's expressions become readable, writable or shareable for the targeted audience. A grant rule with no targets never matches. |
| Access Filter | Filter Visible Records | Narrows access: only records matching the expression remain visible, on top of whatever grants allowed. |
Targets name who the grant is for — the current user or record owner, all internal or all external users, or a specific role, team or business unit. Ownership Resolution and Principal Expansion rule types, the Resolve Owner effect and the Specific Principal audience appear in the form but are disabled; they are not evaluated by the runtime.
Manual shares
A share is an explicit, per-record grant — the escape hatch for exceptions rather than patterns. A share names a principal (a user, role, team, business unit, or all internal or all external users), the record, and the access it grants (read, update, delete, share); it is honoured only while the entity's policy has Allow Manual Share on, and shares to teams additionally need Allow Team Access. Shares are consulted only when the user's baseline does not already reach every record, so they never reduce access.
Share records are administered as security metadata (they require the security-management capability); there is no share dialog on record pages in the current web client. If you find yourself creating the same share repeatedly, encode the pattern as a policy default or an Access Grant rule instead.
Common questions
Why can a user see a record but not edit it?
Because read and write compose differently. The read likely comes from a Read Only default, hierarchy or a share — none of which grants writing. Writing needs ownership, a Read Write default, Modify All, a share whose access includes update, or a Grant Write rule; and independently the user's profile must include Update on the entity. Check the profile grant first, then ask which mechanism was expected to allow the write on this particular record.
Why can nobody else see the records of my new custom entity?
Custom entities start with no sharing policy, and the runtime then treats them as private: only each record's owner and View All / Modify All holders see records, with hierarchy, sharing and team access off. Create the entity's policy under Setup → Access Control → Policies → New Policy and choose the defaults you want — Read Only for both audiences with hierarchy, manual share and team access on matches the platform's own entities.
Does sharing a record with someone guarantee they can open it?
No. A share grants record access, but the recipient still needs Read on the entity from one of their profiles — record grants never widen entity access. The policy must also allow the mechanism: Allow Manual Share on, and Allow Team Access on if the share targets a team. If a shared record stays invisible, check those in order — see Why can't a user see something?.
How do managers see their team members' records?
Through the role hierarchy, not through teams: managers hold a role above their reports' roles, and each entity's policy has Grant Access Using Hierarchy enabled. The roll-up follows record ownership downward through the role tree. Teams are a different mechanism — group access to shared records — so putting a manager in the same team as their reports only helps for records shared to that team.
Does an Organization Owned policy mean everyone can edit everything?
It means record-level filtering is skipped; the profile check still applies in full. A user with Read but not Update on an organization-owned entity sees every record and can edit none.