Granting a manual share is a one-minute operation on the record detail page, but the governance around it matters. Document why the share exists, set the right access level, and consider whether the use case should actually be solved with a sharing rule or restriction rule instead.
- Confirm the standard sharing model does not already grant access
Check OWD, role hierarchy, sharing rules, and any existing manual shares before adding a new one. If the user has access through another path, the manual share is redundant. If many users need the same access pattern, build a sharing rule instead.
- Open the record and click the Sharing button
Lightning: open the record, click the Sharing button in the highlights panel (may need to be added to the page layout). Classic: open the record and click Sharing in the related list. The platform shows the existing share rows for the record.
- Click Add and pick the user, group, or role
The picker lets you choose a specific user, a public group, a role (without subordinates), or a role-and-subordinates. Group-based sharing scales better than user-based because group membership changes propagate automatically.
- Set the access level
Choose Read Only or Read/Write. Cannot exceed the grantor's own access. For sensitive records, default to Read Only and only elevate to Read/Write when collaboration genuinely requires edits.
- Save and verify the new share row appears
The Sharing UI refreshes and shows the new entry. Confirm the access level and target are correct. Salesforce does not send a notification by default, so manually inform the grantee if they need to know they have access.
- Document the share rationale on the record
Add a note to the record (description field, custom Notes field, or Chatter post) explaining why the share was granted. This documentation pays off when the record is transferred and the new owner wonders why these specific users have access.
- Schedule a periodic review
Manual shares can accumulate over time. Build a SOQL query against the Share tables to identify stale shares (last modified more than 6 months ago) and review them quarterly. Remove shares for users who have left the role or company.
Who receives access through the share. Groups and roles scale better than individual users because membership changes propagate automatically.
Determines whether the grantee can view or edit. Cannot exceed the grantor's own access on the record.
Always Manual for user-initiated shares. Apex-managed sharing supports custom Row Cause values for automated scenarios.
- Manual shares are deleted automatically when the record owner changes. The new owner has to re-establish shares if the existing grants are still needed.
- Manual sharing on a parent does not propagate to lookup children. Each child needs its own share. Master-detail children inherit parent sharing automatically.
- The share access level cannot exceed the grantor's own access. Admins with Modify All Data can grant Read/Write; standard users can grant only what they have themselves.
- Manual shares accumulate over time and rarely get cleaned up. Schedule quarterly reviews against the Share tables to remove stale grants before they become audit findings.
- When many users need the same access pattern, manual shares scale poorly. Use sharing rules instead because they propagate automatically as users join roles and groups.