📖 Read · 20 XP

Field-level security

Field-level security

Field-level security (FLS) decides whether a user can read or edit a specific field. It's set on profiles and permission sets, per field:

Visible	Read-only	Effect
✅	⬜	Can see and edit (if they can edit the record)
✅	✅	Can see but not edit
⬜	–	Field is hidden everywhere

FLS is real security. Page layouts aren't.

Removing a field from a page layout only hides it on that page. The user can still reach it via:

• Reports and list views
• The API (Data Loader, Workbench, integrations)
• Apex and LWCs that query it

If a field is sensitive (salary, ID numbers), lock it down with FLS.

Putting the onion together

To read Account.AnnualRevenue on a specific Account, a user needs all of:

1. Object read on Account (profile / permission set)
2. Record access to this Account (OWD / roles / sharing)
3. Field read on AnnualRevenue (FLS)

Apex and FLS

Apex is powerful. By default it runs in system mode, which ignores both FLS and sharing. Production code that serves users should respect them:

// enforce object, field and record security in one go
List<Account> accs = [SELECT Name, AnnualRevenue FROM Account WITH USER_MODE];

You'll practise this properly in Security in Apex.

🦝 If an exam question says "hide this field from users", the answer is FLS. If the answer mentions page layouts, Quill sighs loudly.