Salesforce Dynamic Forms are one of those features that seem like an obvious improvement when you first start using them. Instead of relying entirely on traditional Page Layouts, you can control which fields and sections appear on a Lightning Record Page and use visibility rules to tailor the experience. You can also use visibility filters on components, related lists and tabs. That flexibility is genuinely useful, especially when different groups of users need to see different information.
But flexibility has a downside. I’ve seen Salesforce pages where the logic that determines what a user sees has become almost as complicated as the underlying business process. A field has one visibility rule, the section around it has another, and a related component has a third. Multiply that by dozens of fields and several record types, and suddenly an admin has to work through hundreds of filters just to understand why something is or isn’t showing up.
That isn’t really simplification. It’s moving the complexity from Page Layouts into Lightning App Builder.
When we’re designing Salesforce pages, I prefer to start by looking at the overall page architecture rather than immediately adding visibility rules. How many Page Layouts do we actually need? Are we maintaining separate layouts because different profiles truly have different needs, or because that’s how the system evolved over time? Can we reduce the number of Record Types, layouts and Lightning Record Pages before introducing more conditional logic?
Traditional Page Layouts still have a place. They’re familiar, relatively straightforward to maintain, and sometimes they’re all you need. Dynamic Forms make sense when the user experience genuinely benefits from conditional sections or a more tailored layout. The goal shouldn’t be to convert everything just because the newer feature is available.
When we do use Dynamic Forms, I generally prefer putting visibility rules at the section or tab level instead of on every individual field. If a whole group of information is relevant only for a particular type of record or stage in a process, show or hide the group. That’s usually easier to understand and maintain than giving each field its own filter. There will always be exceptions, but they should be exceptions rather than the default design.
There’s also an important distinction between what appears on the page and what a user is actually allowed to access. Component visibility is a user-experience tool, not a replacement for Salesforce field-level security or other access controls. Those permissions still need to be designed and tested separately.
The question I keep coming back to is whether the next Salesforce admin will be able to understand the design. Can they open the Lightning Record Page and quickly see why a section appears for one user but not another? Can they make a change without worrying about breaking a dozen unrelated conditions? If the answer is no, we’ve probably made the page too complicated.
Dynamic Forms can absolutely make Salesforce easier to use. But only if we use them to reduce complexity rather than create a new place to hide it. Simplify the page architecture first, then add the visibility logic you actually need.
