Why is a Salesforce field blank for some users but not others?

Field-Level Security (FLS) — the user's profile has the field set to 'Hidden' (no read access) or 'Read' without 'Edit'. Profile FLS overrides page-layout visibility, so even if the field is on the layout, the user won't see it. Diagnostic: Setup → Object Manager → [object] → Fields & Relationships → [field] → 'Set Field-Level Security' shows every profile's setting in one view. Or query FieldPermissions: `SELECT Parent.Profile.Name, PermissionsRead, PermissionsEdit FROM FieldPermissions WHERE SobjectType = 'Account' AND Field = 'Account.Custom_Field__c'`. Fix: grant Read (or Read + Edit) to the relevant profile, or — better — create a Permission Set with the access and assign it to the users who need it. Permission Sets compose cleanly; profile edits are blanket grants you can't easily revert.

Why isn't my integration writing to a custom field even though the API call returns success?

This is the 'FLS silent failure' — and it's the most expensive Salesforce data-quality bug because it produces no error. When an API write includes a field the integration user doesn't have Edit on, Salesforce silently drops that one field from the write and saves the rest of the record successfully. You get a 201 Created, the record exists, just without the field you cared about. Fix: query FieldPermissions for the integration user's profile + all assigned Permission Sets, confirm Edit is granted for every field the integration writes. The defensive pattern is to do this check at provision time — when you set up the integration user, audit the field list it'll write to against its effective permissions. Catching it later means a 90-day backfill.

What's the difference between page layout field visibility and field-level security?

They operate at different layers and FLS always wins. Page Layouts control whether a field is displayed on a record's detail page for a specific profile/record-type combination — they're a UI presentation layer. FLS controls whether the field is accessible at the data layer at all — applies to UI, API, reports, list views, Apex, Flows. If FLS says 'Hidden', it doesn't matter that the layout has the field; the user won't see it. If FLS says 'Read' and the layout doesn't include the field, the user has access in principle but the field isn't on the page they're viewing. Debug order: always check FLS first (it's the gating layer), then check page layout. People often spend an hour on page layouts before realizing FLS was the issue.

Can I check all my field-level security settings at once instead of clicking field-by-field?

Yes, three options. (1) Salesforce Security Health Check (Setup → Security Center → Health Check) gives an org-wide score and flags overly permissive defaults but doesn't enumerate per-field state. (2) The FieldPermissions SObject is queryable via SOQL: `SELECT Parent.Type, Parent.Label, SobjectType, Field, PermissionsRead, PermissionsEdit FROM FieldPermissions WHERE Parent.IsCustom = true ORDER BY SobjectType, Field`. Returns every customizable FLS row. (3) BuildForce's security check pivots that data into a 'profile × field × access level' matrix and flags integration users with write-list-vs-access-list gaps automatically. The native UI does not have a 'show me all fields one profile can edit' view; you have to query.

Does Apex code enforce FLS automatically, or do I have to write the checks?

Depends on the API version of the Apex class and whether the class uses 'with sharing' or 'without sharing'. API v49 and earlier: no automatic FLS enforcement; code must call `isAccessible()` / `isUpdateable()` explicitly or use `with sharing` to inherit the running user's sharing rules. API v50+: FLS is enforced automatically for code that uses `with sharing`. Classes still marked 'without sharing' continue to skip enforcement — by design, for system-context operations. The pattern that works: any Apex class doing DML on behalf of a user should be `with sharing` AND should `enforce_user_mode` on the query for v50+ orgs, which makes FLS violations throw clearly rather than silently strip fields.

Should I edit Profile FLS directly or use Permission Sets?

Permission Sets, almost always. Permission Sets are additive — they grant access on top of the profile baseline without modifying the profile. This means you can grant a specific user one field's access without affecting any other user with the same profile. You can revoke by un-assigning the Permission Set, no profile edit required. Direct profile edits affect every user with that profile, are hard to audit, and require touching the profile every time you grant new access. The exception: if a permission really should apply to every user with a profile (e.g., 'Marketing' profile gets 'Marketing fields' access), Profile FLS is appropriate. As of 2024 Salesforce officially recommends 'minimum-permission profiles + composed Permission Set Groups' as the default org-design pattern.

What happens to FLS when I deploy a new field — does it get auto-granted to anyone?

By default, no — and that's the source of a common deploy-followed-by-bug pattern. A new field deployed to production has FLS = Hidden for every profile except System Administrator. Users (and integrations) won't see it until you explicitly grant access. The standard deploy pattern: bundle the field definition + the FieldPermissions metadata (granting access to the relevant profiles or Permission Sets) in the same deploy. If you're using Permission Sets (recommended), the deploy includes the field + an updated Permission Set that grants access; users get the field as soon as the deploy lands. Without that, your deploy lands a 'silent' field that nobody can see until someone notices and goes spelunking.

Fix Guide

How to Fix Salesforce Field-Level Security Issues

Step-by-step fix guide with AI-powered diagnosis from BuildForce.

Salesforce Field-Level Security failures present in three distinct ways and they need different diagnostics. (1) Users see a field as blank when they expect a value — almost always the user's profile has the field marked 'Hidden' and the profile FLS overrides page-layout visibility. (2) Integrations write a record successfully but the field value doesn't appear — Salesforce silently drops fields the integration user can't edit, returning success on the overall write. This is the 'FLS silent failure' that's most expensive to debug because nothing tells you it happened. (3) Apex throws System.NoAccessException at runtime — typically after a class was upgraded to a newer API version that enforces FLS by default. The diagnostic flow: confirm the field exists on the object (Object Manager), check the FLS for the relevant profile (Object Manager → Field → Set Field-Level Security), check the integration user's effective access including assigned permission sets, then audit Apex callers if it's a code path. The fix is almost always to grant access via a Permission Set rather than editing the profile directly — Permission Sets are additive, profile edits are blanket grants that erode the principle of least privilege.

Hidden FieldsIntegration Write AccessFLS in ApexPermission Sets

Get AI-Powered Diagnosis See Pricing

FLS silent failures on integrations are the single most-expensive class of Salesforce bug because they don't fail — they succeed with missing data. Your HubSpot sync POSTs a Contact with phone, email, AND a custom `Lead_Score__c` field. The integration user has Edit on phone and email but not on `Lead_Score__c`. Salesforce returns 201 Created with the record ID. Phone and email are saved. `Lead_Score__c` is silently dropped. The integration logs success. The downstream report shows 'why is our Lead Score column empty?' a quarter later. You discover the bug 90 days after it started.

The defensive pattern is to verify FLS at integration setup, not at debug time. When you provision an integration user, run a SOQL query against FieldPermissions filtered by that user's profile and every permission set assigned to it, then compare against the list of fields the integration intends to write. Any field on the write-list that's not in the access-list is a silent-failure waiting to happen. This is a 5-minute check at provision; a 5-day cleanup after the fact.

FLS in Apex is its own quagmire. Pre-API-v50 Apex classes default to 'without sharing' and don't enforce FLS at all — code can read and write any field regardless of running-user permissions. API v50+ changed the default: Apex now respects FLS unless the developer explicitly suppresses it. This is correct security but creates a subtle deploy hazard: upgrading a class's API version from v49 to v50+ can break the class for users who previously had it working. The class didn't change; the implicit FLS enforcement did. Audit any Apex class you upgrade across the v50 boundary.

Profiles control baseline FLS; Permission Sets add to it but cannot subtract. Permission Set Groups (introduced 2021) bundle Permission Sets for muting/unmuting. As of Spring '26, Salesforce recommends Profile minimum + Permission Set / Permission Set Group composition for all new orgs — the legacy 'every-profile-grants-everything' pattern is officially deprecated.

Source: Salesforce Help — Permission Set Groups and Field-Level Security Best Practices

Symptoms

Fields visible in some user profiles but blank or missing in others

Integration writes failing with 'INVALID_FIELD' or no error but data not saving

Reports showing empty field columns for certain users

Apex code throwing 'System.NoAccessException: No access to entity' in production

Fields visible in Classic but not appearing in Lightning record pages

Root Causes

Profile FLS set to 'Hidden' for the wrong profile

When a user's assigned profile has a field marked as Hidden, they can't see or edit the field regardless of page layout. Profile FLS overrides page layout visibility.

Integration user profile missing Edit access

Integration connected apps run as a specific Salesforce user. If that user's profile doesn't have Edit access to a field, API writes to that field are silently ignored — no error, the data just doesn't save.

Permission sets not applied

Permission sets can grant field access on top of profile restrictions. If the correct permission set wasn't assigned to the user, they won't have the expected access even though the permission set exists.

FLS not enforced in Apex but checked in UI

Page layouts and list views enforce FLS. Apex code using 'with sharing' also enforces FLS in newer API versions. Code paths that work in lower API versions may start throwing FLS errors after a Salesforce upgrade.

How to Fix It — Step by Step

Check effective field access for a specific user

Use the 'View as User' feature in Setup → Users to see exactly what fields a specific user can see and edit. This is the fastest way to confirm an FLS issue.

Example

# SOQL to check FLS for a specific field and user
SELECT Field, PermissionsRead, PermissionsEdit 
FROM FieldPermissions 
WHERE SobjectType = 'Contact' 
AND Parent.ProfileId = '[profile_id]'

Identify which profiles are missing field access

In Setup → Object Manager → [Object] → Fields & Relationships → [Field], click 'Set Field-Level Security'. Review which profiles have Read and Edit access. Profile FLS is the baseline — permission sets can add access but not remove profile access.

Use permission sets instead of editing profiles

Best practice is to grant additional field access through permission sets, not direct profile edits. Create a permission set for the required field access and assign it to the relevant users or integration user account.

Fix integration user field access

For integration write failures, check the integration user's profile and all assigned permission sets for the failing field. Add the field with 'Edit' access to a permission set and assign it to the integration user.

Audit Apex code for FLS enforcement

Search your Apex codebase for 'Schema.sObjectType' and 'isAccessible()', 'isUpdateable()' checks. Ensure code that writes fields verifies the running user has edit access before attempting the DML operation.

Example

// Check FLS before DML
if (Schema.sObjectType.Contact.fields.Custom_Field__c.isUpdateable()) {
  contact.Custom_Field__c = newValue;
  update contact;
}

Scan for FLS issues with BuildForce

Run BuildForce's security health check to get a full audit of field-level security gaps across all integration users and profiles — surfacing fields that integrations can't write to and fields exposed to profiles that should be restricted.

Real-world incidents we've seen

A B2B sales org whose Salesforce-Pardot sync was silently dropping the `Last_Engagement_Date__c` field for 4 months. The Pardot integration user had Read on the field but not Edit. The sync returned success on every record; the field stayed null. Marketing team noticed when they ran a campaign segmentation by engagement recency and the segment was empty. Fix: add Edit access via a Permission Set; backfill the historical values from Pardot's records.
A consultancy upgraded a custom Apex trigger from v48 to v52 to use a new platform feature. The trigger wrote to a custom field. After deployment, the trigger started throwing System.NoAccessException for any user not in the System Administrator profile, because the running-user FLS check started enforcing post-v50. Fix: add `Schema.sObjectType.Account.fields.Custom_Field__c.isUpdateable()` guard before the DML.
A regulated financial services org discovered during an audit that their `SSN_Last4__c` field was visible to every Sales Cloud user — someone had set the FLS to 'Read' on the standard Sales profile two years prior to fix a 'why can't I see this field' ticket. Fix: revoke at the profile level, grant only to the Compliance team via a Permission Set. Auditors required documentation of every user who had access during the 24-month exposure window.