Early in a project for a retail client, we removed a sensitive compensation field from every Page Layout and marked the task done. A week later, their integration team flagged that the field was still coming through in full on every API response. We had made the field invisible in the browser and left it completely exposed everywhere else. That moment clarified something we now explain to every client at the start of a new org build: Page Layout and Field-Level Security are not two ways of doing the same thing. They live in different layers of the platform, they enforce different guarantees, and when they conflict, FLS wins — always.
What FLS Actually Controls
Field-Level Security answers a single question at the data layer: is this user allowed to see or change the value of this field? The three states are straightforward — Read/Write means the user can view and edit the value, Read Only means they can see it but cannot change it, and Hidden means the value is inaccessible to them entirely, regardless of how they try to reach it.
That last point matters more than most admins initially realize. When FLS is set to Hidden, the field does not just disappear from a record page — it returns null in SOQL queries, drops out of reports, and is inaccessible to Apex code running in that user's context. A sales rep with Hidden FLS on an Annual Revenue field will not see it in list views, cannot add it as a report column, and will not receive its value through any API call. There is no side door.
This is why we treat FLS as the actual security control and everything else as presentation. If you are designing an org for a client like a Vietnamese telecom client where certain contract value fields should be visible only to senior account managers, the answer is FLS Hidden on the Profile for everyone else — not removing the field from a layout and hoping nobody notices the API.
What Page Layout Actually Controls
Page Layout is a UI instruction set. It tells Salesforce how to render a record in the browser for a given Profile: which fields appear, in what order, how they are grouped into sections, which related lists show up at the bottom, and which buttons appear in the action bar. It also controls whether a field is flagged as required during a UI-driven create or edit operation.
Everything Page Layout does is scoped to the browser interface. Remove a field from a layout and it disappears from the record detail page — but it remains fully accessible in reports, list views, API responses, and any integration that writes or reads records programmatically. For a a large Vietnamese enterprise implementation we worked on, we had a requirement to hide internal approval notes from frontline staff. We initially assumed layout removal was sufficient. It was not. The notes field appeared in every data export their operations team ran. FLS Hidden was the only fix that worked across all surfaces.
The mental model we use internally: Page Layout is about experience, FLS is about entitlement.
When the Two Layers Conflict
The interaction between FLS and Page Layout follows a consistent rule — the more restrictive setting wins for access, and layout wins only for UI presentation when FLS is permissive. In practice, this plays out in a few important ways.
If a field is Hidden by FLS but appears on the Page Layout, the field does not show up on the record page. FLS overrides the layout silently — the user simply sees a record with fewer fields than the layout technically includes. If a field is Read Only by FLS but is set to editable on the layout, it renders as read-only in the UI. The layout's editable setting has no power to override FLS.
The inverse situation is where we see admins get tripped up. A field can be Read/Write by FLS — meaning the user has full data access — while not appearing on their Page Layout at all. In that case, the user will not see the field in the UI, but they can absolutely reach it through reports, list views, and the API. For a genuine UI-only cleanup (decluttering a record page for a specific role), this is fine. For a security requirement, it is a false sense of control.
We use a simple internal check before signing off any field visibility configuration: if someone used Data Loader or wrote a custom integration, would they still see this field? If yes and the requirement says they should not, FLS needs to be set.
Configuring FLS: Profile Baseline, Permission Set Extension
We always configure FLS with a specific layering strategy. The Profile establishes the minimum — for sensitive fields, that means Hidden by default for all Profiles that should not have access. Permission Sets then extend access upward for specific roles or users who legitimately need it.
Navigating to a Profile and setting Field-Level Security (or Field Permissions in the newer UI) gives you a matrix of every object and field combination. Setting a field to Hidden on the Profile means every user on that Profile starts with no access. From there, a Permission Set can grant Read or Edit on that field and be assigned only to the users who need it.
The important constraint here is that Permission Sets are additive only. A Permission Set can open up access — granting Read or Edit to a field that the Profile hides — but it cannot close access down. If a Profile grants Read on a field, no Permission Set can remove that access for an individual user. This means the Profile needs to be conservative on sensitive fields from the start. The mistake we see most often is an org where the Profile grants broad field access across the board, and then an admin tries to use Permission Sets to lock things down for certain users. It does not work that way. You have to set the restrictive baseline at the Profile level.
The "Required on Page Layout" Trap
We flag this explicitly with every client that has external integrations — and in our experience, that is nearly all of them. A field marked as required on a Page Layout enforces entry through the standard browser interface. It has no effect whatsoever on records created through the API, Data Loader imports, Flow automations that write records without going through a UI screen, or any other non-layout path.
This distinction has caused real data quality problems in projects we have inherited. A client's CRM had a "Contract Start Date" field marked required on every layout, so the business assumed it would always be populated. Their ERP integration was writing Opportunity records via API and skipping the field entirely. Thousands of records had no contract date.
The correct tool when a field must be populated on every record regardless of how it was created is either the universally required field property in Object Manager, which enforces at the database level and causes API writes to fail if the field is missing, or a Validation Rule that checks the same condition. Page Layout required is a UX guard, not a data integrity guarantee.
FLS in Reports and Dashboards
Reports respect FLS faithfully — a field hidden by FLS either does not appear as an available column when a user builds a report, or returns blank values if an admin has pre-built a report containing that field. The user simply cannot see the data.
Dashboards introduce one important nuance we always review with clients: the Running User setting. A dashboard configured to run as a System Administrator will use that admin's FLS permissions to pull data, and viewers who would normally have Hidden FLS on a field may see values surfaced through the dashboard's charts and metrics. Switching the Running User to "Logged-in User" ensures each viewer's own FLS is respected, which is almost always the correct setting when the dashboard contains sensitive data.
List views follow the same pattern as reports. A user with Hidden FLS on a field cannot add it to their list view columns. If an admin creates a shared list view that includes the field, users with Hidden FLS see a blank column — the column renders, but the values do not.
How We Approach This on Every Project
Our standard on any new org build or security audit is to treat FLS as the authoritative access control and Page Layout as a presentation concern that follows from it. We audit sensitive fields first — compensation data, financial figures, personal identifiers, anything the client flags as restricted — and set Hidden at the Profile level before we touch layouts. We then build Permission Sets for the roles that need access and assign them deliberately.
The one habit that has saved us the most remediation work: before closing any security configuration task, we run a quick check as a test user with restricted access. Not in the UI alone — we use the API or run a SOQL query in Developer Console as that user's context to confirm the field truly returns null. Layout hiding is invisible to that test. FLS failure is immediately obvious. That fifteen-minute check has caught more gaps than any documentation review.
