Layouts and Dynamic Forms

Module 3 of 6 in the chapter Object and Field Security: What Users Can Touch, chapter 4 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: If a field isn’t on the screen, can the user still see it, and what are layouts and visibility rules really for?

Here’s a question for you. If a field isn’t on the page, can the user see it?

Most people say no. That’s the answer this module is here to change. In class, a student once solved a hard field problem with a visibility filter on a Lightning page. Very good, I said, but there’s a problem. You can keep it off the screen, but you can’t keep it from other mechanisms.

Three ways to hide a field on the screen

Salesforce gives you three ways to decide what a user sees on a record page.

• Page layouts. They “control the layout and organization of detail and edit pages,” and decide whether fields are “visible, read only, or required, on detail and edit pages only” (Ways to Control User Access to Fields (opens in a new tab), Salesforce Help, checked 2026-11-01). Chapter 3, module 1 showed the page layout matrix: profiles down one side, record types across the top.
• Visibility rules on Lightning pages. On any component, filters decide when it appears. “On record pages, you can filter on record fields or advanced fields, such as fields from related objects or from a global object like User,” and a filter on the Device context shows a component only on a phone or a desktop (Visibility Rules on Lightning Pages (opens in a new tab), Salesforce Help, checked 2026-11-01).
• Dynamic Forms. The same rules, on single fields and field sections. “You can have a field or set of fields hidden until a person with a certain profile, permission, or viewing on a certain device visits the page” (same page).

All three are about the screen. That’s the point of this module.

Click to enlarge

Paul’s airport page

Back to Paul and the Security Status field from module 2. Pilots have Read on it, through View Airports. Now the airline wants it shown only on large airports.

So I edit the airport page in the Lightning App Builder and upgrade it to Dynamic Forms. On the Security Status field, I add a visibility filter: Type equals Large Airport. Save. Open a small airport, and there’s no Security Status at the bottom. Open a large one, and there it is. I could also filter on the user instead, and read attributes of the user who’s looking.

That’s powerful, and it’s good design. But here’s the key element to remember: you had to have granted field-level security already. The filter can only hide a field the user already has. If Paul didn’t have Read, the filter wouldn’t matter: the field wouldn’t be there at all.

The list view I build next

Now the demo that changes people’s minds. Still as a user with Read on Security Status, I go to the Airports tab and create a list view. Call it Steve test, only I can see it. I add the Security Status column.

And there’s every airport’s security status, small airports included. The ones I hid on the page are right there in the list. The same values would be in reports and dashboards, and in global search.

Salesforce says it plainly: “If you hide a field with a visibility rule, users don’t lose access to the field’s data.” The values still show in reports, dashboards and list views. “Hidden fields are for user convenience, not for field-level security” (Dynamic Forms Tips and Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).

It says the same about page layouts: “When you use page layouts to hide fields from detail and edit pages, users can still see these fields via reports, search results, list views, and the API.” And: “Don’t use page layouts to secure data. For example, removing the Edit button from a page layout doesn’t prevent users from using inline editing” (Ways to Control User Access to Fields (opens in a new tab)).

So the rule I give every class: don’t use conditional field visibility for fields whose values truly need to be secured. Module 4 walks through every place a granted field shows up.

Click to enlarge

Traps on the page itself

Even as a tool for the screen, visibility rules have edges worth knowing. From the same two Salesforce pages:

• Hidden and required. “If a field is set to Required in the Lightning App Builder, and it’s hidden by a visibility rule at run time, users can save the record even if that field isn’t populated” (Visibility Rules on Lightning Pages (opens in a new tab)). If a value must be filled in, use a validation rule, not the page.
• Hidden and edited. “If a field is hidden on a page due to a visibility rule, and a user edits the value of the field, its new or changed value isn’t saved” (Dynamic Forms Tips and Considerations (opens in a new tab)).
• Desktop only, unless you turn it on. Field and field section components “are supported on desktop only,” so their rules are “respected only in the desktop view, not on mobile,” unless you enable Dynamic Forms on Mobile in Salesforce Mobile App Setup (same page).
• Dependent picklists. They “don’t respect visibility rules,” and still appear in the View All Dependencies list (same page).
• Sections wait for a save. Rules on single fields react while the user edits; rules on field sections “are evaluated only after the record is saved” (same page).

None of these is a reason to avoid Dynamic Forms. They’re reasons to test the page as the user, on every device they use.

So what are they for?

Layouts and visibility rules are good tools. They make a page fit the record, the user and the device. They show the security status on the airports where it matters, and keep the page short everywhere else. Chapter 3 showed that they also let you “Reduce the number of page layouts and record types you need.” That’s real value.

Just don’t ask them to do security’s job. Before you hide a field, ask two questions:

1. Should this person ever see this value? If the answer is no, that’s field-level security, from module 2. Take the field away.
2. Should they see it here, on this record, right now? That’s a visibility rule. It’s convenience, and it sits on top of field-level security, never instead of it.

And if the answer to the first question is “only in certain cases,” such as only on records assigned to them, neither tool solves it. Module 5 is that problem.

Click to enlarge

What an architect decides here

• For each sensitive field, that its protection is field-level security, not a page layout or visibility rule.
• Where visibility rules are used for convenience, and that every one of them sits on a field the user is allowed to see anyway.
• That required values are enforced by validation rules, not by the page.
• Whether Dynamic Forms on Mobile is turned on, so the page behaves the same on every device.
• How pages are tested: as each kind of user, on each device.

Beyond the exam: what AI changes. An agent doesn’t read your page layout. It works through actions and the API, and Salesforce already says page layouts don’t hide fields from the API. So for an agent, every visibility rule on every page is invisible: the only things that count are field-level security and sharing. If you’ve been relying on the page to hide something, an agent will find it first. Chapter 20 covers agents.

Explore

• Dynamic Forms Tips and Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Visibility Rules on Lightning Pages (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Ways to Control User Access to Fields (opens in a new tab), Salesforce Help (checked 2026-11-01)