Field-level security (FLS) controls which individual fields a person can see or edit, independent of whether they can open the record. It is enforced by one platform-wide engine, so a rule applies in the UI, in Reports, in exports and APIs, and in what Cortex is allowed to read.
Access levels
- Editable - the field is visible and can be changed.
- Read-only - the field is visible but locked.
- Hidden - the field does not appear and cannot be read, filtered on or aggregated.
Configuring a rule
- 1Open /settings/field-access.
- 2Choose the object (for example Employee, Deal, Contact).
- 3Select the field to protect (for example salary or margin).
- 4For each role, set Editable, Read-only or Hidden.
- 5Save, then verify by viewing a record as a user with that role.
How it is enforced
Server-side code asks the field guard (getFieldGuard) which fields the current user may read or write for an object, then strips hidden fields before data is returned and rejects writes to locked fields. Because this is server-side, it cannot be bypassed by an API call or a modified client.
guard = getFieldGuard(user, "Employee")
guard.canRead("salary") // false for Hidden
guard.canWrite("salary") // false for Read-only or HiddenInteractions to know
- Custom fields created at /settings/fields appear in field access automatically and default to visible.
- Hidden fields are unavailable as report metrics, dimensions and filters for that role.
- Import and export honor the same rules, so restricted fields are omitted or rejected.
- Admin roles can be restricted too; do not assume Super Admin bypasses a rule you set for other roles.
Protect sensitive fields before broad rollout. Tightening after data has been exported or shared cannot recall those copies.