OrgReady

Salesforce Skills & Readiness

← Prepare for Your Next Developer Role

Lesson 11 of 18 · 5–7 minutes

Field-Level Security

Object access is only the first layer. Sensitive values need field-specific read and edit permissions even on visible records.

Learning sequence · data model first, security layers next
  1. What CRM and Salesforce Do
  2. The Salesforce Ecosystem and Major Clouds
  3. Org, App, Object, Field, and Record
  4. Standard and Custom Objects
  5. Common Standard Objects
  6. Field Types and Data Quality
  7. Objects, Fields & Records
  8. Lookup vs Master-Detail
  9. Many-to-Many Relationships and Junction Objects
  10. Profiles, Permission Sets & Object Access
  11. Field-Level Security
  12. OWD and Least-Privilege Record Access
  13. Opening Access: Role Hierarchy, Sharing Rules, Public Groups & Apex Sharing
  14. Apex First Steps
  15. Variables and Collections
  16. SOQL and DML Basics
  17. Why Asynchronous Apex Exists
  18. REST Callout Introduction

Your focus

Prepare for Your Next Developer Role

REVIEW · Review • Apply • Practice

  • Diagnose permissions versus layout visibility and test Read versus Edit.

Learning objective

Diagnose a hidden or read-only field without broadening record access.

Before you start

Profiles, permission sets and object access.

Real-world scenario

An agent can open an Account but must not see a sensitive financial field. Keep legitimate Account access and withhold that field permission. For finance users, grant only the necessary field visibility or editability.

The concept

Field-level security (FLS) controls field visibility and editing through permission assignments. Evaluate effective field grants together with object and record access. A field hidden by FLS stays hidden in standard interfaces that enforce those permissions, including reports and APIs. Removing a field from a page layout is presentation, not a security boundary. Custom Apex execution has additional enforcement responsibilities; its runtime security is a later topic.

Check the affected user’s object access, all profile/permission-set field grants, and then page layout or component visibility. A field might be absent for either security or presentation reasons. Test with an agent and finance user; also review derived fields and exports for unintended exposure.

User → Object Access → Field-Level Security

These checks complement record access; passing one layer does not bypass the others.

  1. 1.User

    Support agent.

  2. 2.Object access

    Can read Accounts.

  3. 3.Field-level security

    Cannot read the sensitive financial field.

  • User connects to Object access: needs object permission
  • Object access connects to Field-level security: still needs field permission

Common mistake

Making OWD public to fix a hidden field broadens record access without granting the missing field permission. Hiding the field only on a layout still leaves other access paths.

Interview angle

“The record is shared, but AnnualRevenue is missing.” Identify FLS as a separate layer, inspect effective grants, and check layout visibility only after permissions.

Pause and apply

Define expected read/edit results for an agent and a finance user on the same field. How would you test that a second permission set does not accidentally restore access?

Official references

Reviewed 2026-09-22. Examples are illustrative; no code is executed here.

Key takeaways

  • Record visibility does not imply field visibility.
  • Layouts arrange information; FLS protects fields.
  • Validate both allowed and denied cases using representative users.

Practice next

Diagnose an Account field that remains hidden even though the record is visible.

Record Visible but Field Hidden

Reading these lessons does not yet save completion. Challenge results continue to provide assessment evidence.