Removing a field from a page layout hides it from that one record detail/edit page only — the field still exists, is still queryable via SOQL, still appears in reports, and is still returned by the API for users whose Field-Level Security (FLS) permits read. Hiding via FLS blocks the field across the entire platform — UI, API, SOQL, reports, list views — for any user whose profile or permission set has FLS Read disabled on that field. FLS is the real security boundary; page layout is presentation.
The comparison interviewers care about
| Scenario | Hidden via Page Layout | Hidden via FLS |
|---|---|---|
| Field visible on the record detail page | No | No |
| Field visible on quick actions / list views | Possibly yes | No |
| Field returned by SOQL / SOSL | Yes | No (filtered out or error) |
| Field returned by REST/SOAP API | Yes | No |
| Field available in Report Builder | Yes | No |
| Field visible in Data Loader / Workbench | Yes | No |
Field accessible from Apex (without WITH SECURITY_ENFORCED) | Yes | Yes — but enforce with Schema.sObjectField.isAccessible() |
| Different per profile/perm set | Page layout assigned per profile — yes, indirectly | Yes — FLS is per profile + per perm set |
| Real security boundary | No — purely UI | Yes |
Why this matters
A real example we see in interviews:
“The HR team asked you to hide the Social Security Number field on the Contact page from the sales team. You removed it from the Sales User page layout. Did you secure the data?”
No. A sales user can:
- Open Workbench, run
SELECT Id, SSN__c FROM Contactand read every value. - Build a custom report including the SSN field.
- Use a list view that includes the SSN column.
- Call the REST API and pull the field for any record.
Hiding via page layout removes a field from one screen. FLS removes it from the user’s view of the platform.
When each one is the right tool
- Use page layout when the field is fine to access but doesn’t belong on a specific layout — e.g., the Industry field exists for all account types but only matters on the “Enterprise Account” page layout. There’s no security implication; it’s just a screen design choice.
- Use FLS when the field is confidential or role-restricted — SSN, Date of Birth, Salary, internal-only notes, anything compliance-sensitive. FLS is the security control.
Best practice: assume any field with a compliance or privacy implication needs FLS first. Page layout is a separate concern handled by the design of the page itself.
How FLS interacts with profile and permission set
FLS is set independently per profile and per permission set. The user’s effective access is the union — if either the profile or any assigned permission set grants Read, the user has Read.
User effective FLS Read = (profile.fieldRead OR any permSet.fieldRead)This means you cannot use a permission set to remove access a profile grants. To restrict, you must either change the profile or use a Permission Set Group with muting permissions.
How page layouts interact with profile
Page layouts are assigned per profile (and per record type if record types are in play). When a user opens a record, Salesforce shows them the layout assigned to their profile + the record’s record type. So you can show the SSN field on the “HR Power User” layout and hide it from the “Sales User” layout — but, again, that only changes what the screen renders, not whether the user can read the data through other channels.
Common interview follow-up
“What if I make the field required on the page layout and hide it via FLS?”
A required-on-layout + FLS-hidden field will cause record saves to fail for users without Read on the field — the page can’t satisfy the requiredness with a value it can’t see or write. This is a frequent admin gotcha. Best practice: do not mark a field “required on layout” if any user role lacks FLS access to it. If the business needs the field required, enforce it with a validation rule and FLS-grant Read at minimum to all users who edit the record.
Verified against: Salesforce Help — Field-Level Security and Page Layout Basics. Last reviewed 2026-05-17.