Security roles and business units control access at the record level — can this user see this record at all. Field-level security goes one layer deeper, controlling access to specific columns within a record that’s otherwise fully visible.
How it works
A column is first marked “field-securable” (a property on the column itself). Then one or more Field Security Profiles are created, each granting Read, Create, and/or Update permission for that specific column, and users or teams are added as members of the relevant profile. Anyone not in a profile that grants access simply doesn’t see the field at all (or sees it masked, depending on configuration) — even if their security role would otherwise let them see the whole record.
Typical use cases
- Salary or compensation fields on an Employee table, visible only to HR and direct managers.
- A sensitive internal note field on a Case, hidden from external-facing agents but visible to specialists.
- A government ID or bank account number, restricted even from most internal staff who can otherwise fully edit the record.
Field-level security is additive, like security roles. There’s no profile that “removes” access a security role already grants to the rest of the record — it only restricts the specific secured columns from users who aren’t members of a profile granting them access. Design it as an extra lock on specific fields, not a replacement for table-level security.