04.02.03 — Field-Level Security and UI Illusions

Lesson goal

This lesson explains why Field-Level Security (FLS) is the ultimate authority on field access and how UI configuration can create dangerous false assumptions during testing.

After completing this lesson, you should be able to:

• understand how FLS interacts with Page Layouts and Lightning Pages
• identify common UI illusions related to field editability
• design test cases that validate effective field access, not visual hints
• distinguish security blocks from validation logic failures

This lesson builds on 04.02.01 (Profiles vs Permission Sets) and 04.02.02 (CRUD Testing).

The problem: the field that looks editable

Field-Level Security (FLS) controls whether a user can see and edit a field — regardless of:

• Page Layout configuration
• Lightning Page design
• Custom component behavior

The core risk is the UI illusion:

a field may appear on screen, look editable, or even accept input — while FLS silently blocks the save operation or should block access entirely.

As QA, we must test effective security, not visual presentation.

FLS vs UI configuration: hierarchy of control

FLS operates at the database level and is the highest authority for field access.

Control layer	Responsibility	QA implication
Field-Level Security (FLS)	Defines whether a user can read or edit field data via UI or API	Must always be tested explicitly via Profile / Permission Set
Page Layout / Lightning Page	Controls whether the field is shown and how it appears	Visual-only layer, never a security guarantee
Validation Rules	Enforce data correctness	May block saves even when FLS allows editing

If these layers conflict, FLS always wins.

Read-only illusion: visible but not editable

The most common illusion occurs when:

• a field is visible on the layout
• but FLS is set to Read Only

Test focus

• Precondition: User has Read access but no Edit access via FLS.
• Action: Open the record, click Edit, attempt to change the field value.
• Expected result:
• the field is non-editable (grayed out), or
• the save fails with Insufficient Privileges

If the user can successfully change and save the value, FLS is misconfigured or bypassed.

Required fields hidden by FLS

A high-risk configuration occurs when a field is:

• Required at schema level
• Hidden via FLS for a user

Test focus

• Precondition: Field is required but hidden for the user.
• Action: User attempts to create or save a record.
• Expected result:
• user is not blocked by an invisible requirement
• system handles the value via default, automation, or design workaround

If the user is blocked without visibility, the configuration is broken and must be escalated.

FLS and custom components (LWC / Aura)

Custom components do not automatically enforce FLS.

Developers must explicitly check field accessibility in code.

Test focus

• Precondition: User has restricted FLS on a field rendered in a custom component.
• Action: Open the record page containing the component.
• Expected result:
• no field value shown if Read access is missing
• field rendered as read-only if Edit access is missing

If sensitive data appears despite restricted FLS, this is a critical security defect.

Practical QA strategy

Always verify FLS in Setup first

Before executing a test:

1. Check the user's Profile and Permission Sets in Setup.
2. Confirm expected FLS behavior for the field.
3. Document expected access in Preconditions.

This prevents subjective testing and clarifies expected results.

Distinguish security blocks from validation blocks

Negative test cases must clearly identify why a save fails.

Block type	Root cause	Expected behavior
Security block	FLS / Profile restriction	Insufficient Privileges
Validation block	Business rule violation	Custom validation error message

Confusing these leads to false defect reports.

Summary

Field-Level Security is the golden rule of field access in Salesforce.

From a QA perspective:

• UI visibility does not equal permission
• Page Layouts never guarantee security
• custom components must explicitly enforce FLS

By focusing on negative testing, validating error types, and testing beyond visual cues, QA prevents UI illusions that can lead to serious security vulnerabilities.

What’s next

In the next lesson, we connect security and data ownership:
04.02.04 — Record Ownership, Role Hierarchy, and Access Control