Field-level security (FLS)
Field-level security (FLS) is the Salesforce permission that controls, for each field of an object, whether a user can read it, read and edit it, or not see it at all. It is granted through profiles, permission sets and permission set groups, and it applies across the UI, reports, list views and the Salesforce APIs.
Access levels and where FLS applies
In a permission set a field can be set to Read and Edit, Read, or no access; the profile UI uses the older labels Visible, Visible and Read-Only, and None. The restriction applies to record pages, related lists, list views, reports, imported data, Experience Cloud sites and the Salesforce APIs — hiding a field from a page is not the same as restricting it.
FLS and page layouts
When a page layout and field-level security disagree, the most restrictive setting wins. A field marked required on the layout but read-only in FLS stays read-only. Salesforce notes two exceptions worth knowing: formula and roll-up summary fields can display values derived from fields the user cannot see, and universally required fields appear on edit pages regardless of FLS.
FLS in Apex
Whether Apex enforces FLS depends on the mode it runs in. The Apex Developer Guide states that from API version 67.0 Apex runs in user mode by default, while in version 66.0 and earlier system mode is the default — so older code does not enforce field permissions unless it asks to.
Enforcement is explicit: WITH USER_MODE on SOQL, insert as user and the other DML forms, AccessLevel.USER_MODE on Database methods, or Security.stripInaccessible to remove fields the user cannot access. Salesforce recommends WITH USER_MODE over WITH SECURITY_ENFORCED.
How aprity helps
aprity documents access from the metadata — profiles, permission sets and field-level security — read-only, so the permissions on a field can be read alongside the automation and business rules that use it. An impact analysis on a field lists the components that depend on it.
Related terms
- Permission set group — A bundle of permission sets assigned as one unit, typically per job role, with an optional muting permission set to switch permissions off.
- Apex trigger — Apex code that runs automatically before or after records of an object are inserted, updated, deleted or undeleted.
- Salesforce Dependency API — The Tooling API object MetadataComponentDependency, which returns which metadata components in an org reference which others.
Sources
Official Salesforce documentation this entry was checked against. Platform behaviour changes between releases; the linked page is the reference.