Salesforce Field-Level Security Testing
Salesforce field-level security testing proves that each persona can read and edit exactly the fields it should — and that compensation, PII, financial and internal-only fields stay hidden or read-only everywhere else. It exercises field permissions from profiles and permission sets across every surface that can show a field value, from page layouts and reports to the API, Apex controllers and flows.
Field-level security is where most silent data exposure starts, because a readable field raises no error.
What field-level security governs
Field-level security, or FLS, sets two flags for every field and every persona: Read Access and Edit Access. Those flags live in field permissions on profiles and permission sets, and like all Salesforce permissions they are additive — if any assigned profile, permission set or permission set group grants read access, the user can read the field. A muting permission set inside a group is the only way to take a field permission back out of a bundle.
The platform enforces FLS in standard user interfaces, reports, list views, global search and the REST, SOAP and Bulk APIs. A user without read access will not see the field on a record page and will get an error if they query it by name through the API. That enforcement is consistent, which is why FLS is the right place to protect a field — and why misunderstanding its boundaries is so costly.
What FLS does not do is follow custom code or automation automatically. Apex runs in system mode by default, flows can run in system context, and formula fields evaluate the fields they reference regardless of whether the viewer can see those source fields. Field-level security testing therefore has to cover both the platform surfaces and the custom paths that can bypass them. Object-level CRUD and record visibility are separate layers; see permission set testing and sharing rule testing.
Where a field value can surface
Each surface needs its own assertion, because a field that is correctly hidden on one can still be exposed on another.
| Surface | Does FLS apply automatically | What to test |
|---|---|---|
| Record pages and page layouts | Yes — layouts only arrange fields the user can already read | A field removed from a layout is still hidden by FLS, not just absent from the layout |
| Reports, list views and search | Yes | Restricted fields cannot be added as report columns, filters or list view columns |
| REST, SOAP and Bulk API | Yes | Querying or updating the field returns an error rather than a value |
| Apex behind LWC and Aura | Only if the code uses user mode, WITH SECURITY_ENFORCED or stripInaccessible | Controllers do not return restricted field values to the component |
| Flows | Depends on the run context configured for the flow | Screen flows and autolaunched flows do not display or write restricted fields for the running user |
| Formula fields | Applies to the formula field itself, not its source fields | A formula visible to a persona does not reveal the value of a hidden source field |
| Field history and feed tracking | History of a field follows that field's access | Old values of a restricted field do not appear in history related lists or feeds |
| Exports and integrations | Yes for the exporting user's session | Data Loader or report exports by a persona exclude restricted columns |
How field access fails silently
None of these failures throws an error for the user who benefits from them, which is why they survive testing that only checks the happy path.
New-field defaults
The new custom field wizard asks which profiles get visibility. Accepting a broad default makes a sensitive field readable for every profile on day one.
Layout used as a control
Removing a field from a page layout feels like hiding it, but the value still returns in reports, list views and API queries if FLS allows reads.
Formula field leakage
A formula that concatenates or derives from a salary or score field exposes that value to anyone who can read the formula.
System-mode Apex
A controller that queries without enforcing user mode passes restricted fields straight to a Lightning component the persona can open.
One permission set, many holders
A field permission added to a permission set for one team is inherited instantly by every other user who holds that set or a group containing it.
Edit without read review
A persona intended to have read-only access gains Edit Access through an additional set, so integrations or inline edits can change the value.
Positive and deny assertions, field by field
Field-level security testing works best when the intended state of each sensitive field is written down per persona and tested in both directions.
Classify the sensitive fields
Start from field metadata such as Data Sensitivity Level and Compliance Categorization, plus known compensation, identity and financial fields, to decide which fields need explicit tests.
Build a field-by-persona grid
For each sensitive field and persona, record the intended state: hidden, read-only or editable. This grid is the specification.
Assert the allowed state
As each persona, confirm the field is visible where intended and editable only where intended, so legitimate work is not blocked.
Assert the deny state on every surface
As each restricted persona, attempt to read the field through the record page, a report, the API and any custom component, and pass only on a clean block.
Probe derived and indirect paths
Check formula fields, roll-up summaries, history lists and flow screens that reference the protected field for indirect disclosure.
Attempt edits where read-only
Try inline edit, API update and flow updates for read-only personas and confirm the value is unchanged afterward.
Field categories to prioritize
Not every field needs a dedicated test. These categories usually carry the highest exposure and audit interest.
- Compensation and commission fields on user, employee or opportunity split records.
- Government identifiers, dates of birth and health or benefits data held on contacts, person accounts or custom objects.
- Cost, margin, floor price and approval discount fields that partners and junior sales roles must not see.
- Credit limits, payment terms and bank details synchronized from finance systems.
- Internal case comments, escalation notes and investigation fields in service and HR use cases.
- Fields holding masked or tokenized values in sandboxes, which should be checked alongside data masking.
- Encrypted fields where the View Encrypted Data permission, not FLS alone, decides whether plaintext is shown.
Field-level security test scenarios
Scenarios like these turn the field-by-persona grid into re-runnable checks.
| Scenario | What it proves |
|---|---|
| Sales rep queries Annual_Salary__c through the REST API | The field is blocked at the API, not merely missing from the rep's layout |
| Service agent adds Internal_Notes__c as a report column | Reports honor FLS for the agent and the column cannot be selected |
| Partner opens an opportunity through a custom LWC | The Apex controller strips cost and margin fields before returning data |
| Finance analyst edits Credit_Limit__c inline | Read-only access holds in the UI and the value is unchanged |
| Manager views a formula field derived from a hidden score | The formula does not disclose the protected source value |
| New field deployed in a release | Only the intended permission sets grant access after deployment |
| User loses a permission set assignment | Field access is removed immediately and the field disappears from every surface |
Evidence and keeping FLS current
Auditors rarely ask whether a permission set grants read access to a field; they ask who can see it. A field-level security suite answers that question with evidence: the persona, the field, the surface tested, the expected state and the actual outcome, retained per run. That record is far more convincing than a screenshot of a field permissions page, because it shows the effective result of every grant combined.
FLS changes with almost every release. New custom fields, managed package upgrades that add fields, and permission set edits all shift field access. Keeping the grid current means adding a test whenever a sensitive field is created and re-running the field suite on each deployment and seasonal release, as part of security regression testing. Where permission set comparison shows that field permissions changed between orgs, the affected field tests are the ones to run first.
What SyntraFlow is designed to do
These capabilities are available for demonstration and proof-of-concept validation.
Persona-based field checks
SyntraFlow is designed to run field assertions as a defined persona, so results reflect effective access across the profile and every assigned permission set.
Multi-surface assertions
A single field test can be configured to check the record page, reports and API access, so a field hidden in one place but exposed in another is caught.
Deny-by-default scenarios
Tests can pass only when a restricted field is blocked, making over-provisioning a failed run rather than a finding in an audit.
Change-triggered re-runs
When field or permission metadata changes, the relevant field tests can be selected and re-run instead of the entire suite.
Related pages
Salesforce security testing
The hub for validating every Salesforce access layer by persona.
Permission set testing
Tests the permission sets and groups that grant most field permissions.
Negative access testing
The deny-case discipline behind every hidden and read-only field assertion.
Permission set comparison
Surfaces field permission differences between orgs before you test their effect.
Data masking
Protects the values in sensitive fields when production data reaches sandboxes.
Security regression testing
Re-runs field access tests after every change and seasonal release.
Field-Level Security Testing testing FAQs
What is Salesforce field-level security testing?
It is the practice of proving, persona by persona, that each field is hidden, read-only or editable exactly as intended. Tests check the effective result of all profiles, permission sets and groups, and assert that restricted fields are blocked on every surface that can display or change them.
Does removing a field from the page layout hide it?
Only from that layout. If field-level security still grants read access, the value can appear in reports, list views, search results and API queries. Page layouts arrange accessible fields; FLS is what decides access, so tests must assert against FLS rather than layout presence.
Does Apex respect field-level security?
Not by default. Apex runs in system mode unless the code opts in to enforcement, for example by running queries in user mode, using WITH SECURITY_ENFORCED or applying Security.stripInaccessible. Testing custom components as a restricted persona is the reliable way to confirm a controller does not leak protected fields.
Can a formula field expose a hidden field?
Yes. Field-level security applies to the formula field itself, and the formula evaluates its source fields regardless of whether the viewer can read them. If a persona can see the formula, any value it derives or reveals from a protected field is exposed, so formulas referencing sensitive fields need their own tests.
How is FLS testing different from permission set comparison?
Permission set comparison shows how field permissions differ in metadata between sets or orgs. Field-level security testing proves the effective behavior for a real persona once every grant is combined, across the surfaces where the field can appear.
How often should field-level security tests run?
At minimum on every deployment that adds fields or changes permission sets, and before each seasonal release reaches production. Many teams also run the sensitive-field subset on a schedule, so a manual change made directly in production is detected quickly.
Keep sensitive fields out of the wrong hands
See how persona-based field-level security testing proves every protected field is hidden everywhere it should be.