Every mechanism covered so far — business units, security roles, hierarchy security, teams, field-level security — is built for the general case: a job function, a department, a category of sensitive field. Every so often, though, one specific person needs into one specific record, just once, for a reason that has nothing to do with their normal job.
Restructuring a business unit or handing out a broader security role would be overkill for that. This is exactly what record sharing is for.
- Sharing grants access to one record, to one user or team, for chosen privileges
- It never touches the recipient's role, business unit, or team memberships
- Uses the same privilege vocabulary as security roles, applied to a single record
- Revoking a share removes access to that record and nothing else
Lending one book, not the house key
Sharing a record is like lending a neighbor a single book off your shelf, instead of handing them a key to your whole house. They get exactly that one book, for exactly as long as you're willing to lend it — nothing else on the shelf or in the house is affected. You can take it back whenever you like, without changing a single lock.
Record sharing works the same way: it grants access to one particular record, to one particular person or team, and it can be revoked at any time without touching their security role, business unit, or team memberships.
What gets shared, and how much
When you share a record, you choose exactly which privileges to extend — the same seven-privilege vocabulary from the Security Roles chapter, but applied to just this one record instead of a whole table:
| Privilege | What it lets the recipient do with this one record |
|---|---|
| Read | Open and view this specific record |
| Write | Edit this specific record's fields |
| Append | Attach this record to another record they have access to |
| Append To | Attach some other record of theirs onto this one |
| Assign | Hand ownership of this specific record to someone else |
| Share | Share this same record onward with a third person themselves |
You don't have to grant all six. Often just Read, or Read plus Write, is exactly enough — the same way lending a book doesn't come with permission to lend it onward unless you say so.
Revoking is just as targeted
Because a share only ever touches one record, taking it back is equally contained — un-sharing removes access to that record and nothing else. There's no risk of accidentally rolling back some broader change, because no broader change was ever made.
That narrowness is precisely what makes sharing a safe, low-stakes tool to reach for whenever the need is genuinely one-off.
When sharing is the wrong tool
Sharing earns its keep by being narrow — but that narrowness is also its limit. If the same kind of access keeps getting shared to the same person or team over and over, one record at a time, that's usually a sign the need isn't really one-off anymore.
A security role, business unit change, or team membership would serve better than a growing pile of individual shares. Sharing a handful of records to a colleague helping out for a week is a good use of the tool; re-sharing dozens of records every week to someone who's really becoming part of a team is a sign to reach for one of the broader mechanisms covered earlier in this course instead.