Everything so far in this course has worked at the level of the whole record — can this user open this Account, this Case, this Opportunity at all? Field-level security drills down one layer further: even after a user is allowed to open a record, specific individual fields on it can still be locked away from them.
- A field is marked secured before it can be locked down at all
- By default, once secured, nobody sees the field until explicitly granted access
- Field security profiles grant Read, Update, and Create per field, per profile member
- Securing a field applies to every record on that table — no per-record exceptions
A redacted document
Picture a printed document that's been redacted before being handed out. Everyone holding a copy sees the same page and layout — but a few lines are blacked out for anyone without clearance, while a smaller group gets to read the whole thing.
Field-level security works exactly like that redaction. Two users can open the same record and see largely the same information, but one sees blank or masked values in a field the other reads in full.
Secured fields and field security profiles
Making this work takes two pieces. First, an administrator marks a specific field on a table as secured — flagging it as a line that should be capable of being blacked out. By default, once secured, nobody can see it until they're explicitly given permission.
Second, the administrator creates one or more field security profiles and adds specific users or teams to them. Each profile grants a combination of permissions on the secured field:
| Permission | What it controls, for this one field |
|---|---|
| Read | Whether the profile's members can see the field's current value at all |
| Update | Whether they can change the value on an existing record |
| Create | Whether they can set the value when the record is first created |
Anyone who isn't a member of a profile granting Read on that field simply doesn't see its value — usually shown blank or masked on the form — regardless of what their security role or business unit would otherwise allow on the record as a whole.
An exception, not a replacement
Field-level security is meant for a small handful of especially sensitive fields — government ID numbers, salary, or similar data that most people with legitimate record access still shouldn't see. It isn't a replacement for the record-level protections built from business units, security roles, hierarchy security, and teams.
- Marking too many fields as secured makes forms harder to reason about and administer
- Used sparingly, on the few fields that genuinely need it, it's a precise tool rather than a blunt one
- It has no concept of business units or record ownership — a profile's membership is just a flat list of specific users and teams
- That makes it a poor fit for anything that should scale automatically as the company grows, but exactly right for a short, stable list of people who need an exception regardless of business unit
One more detail worth knowing: securing a field affects every record on that table, everywhere, the moment it's turned on — there's no way to secure it for only some records and leave it open on others. A genuinely record-specific need — one record needing tighter or looser access than the rest of its table — is a job for record sharing, covered next, not field-level security.