4.5 Dynamic Forms, Dynamic Actions, and User Experience

Building Context-Aware Record Pages

Lightning App Builder gives admins a component canvas for building record pages, app pages, and home pages. Dynamic Forms and Dynamic Actions extend that model by making fields, field sections, and actions more responsive to context. Instead of showing every field to every user all the time, the page can reveal what matters for the current record type, status, profile, permission, or field value.

Dynamic Forms let an admin place fields and field sections directly on a Lightning record page where supported. This gives more control than a single Record Detail component because sections can be arranged near related components and controlled with visibility rules. For example, an escalation section can appear only when Case Priority is High, or an implementation section can appear only for enterprise opportunities.

Dynamic Actions let an admin manage record actions in the Lightning page experience. Actions can be shown or hidden based on filters such as record field values, user context, or device conditions where available. This helps users focus on the next reasonable action. A closed case may show Clone and Reopen while hiding actions that are only useful during active work.

The security distinction matters. If a sensitive field is hidden only with component visibility, the data may still be accessible through reports, list views, API access, search, or another page if field-level security permits it. The admin should set object permissions and field-level security first, then use Dynamic Forms to make the page cleaner. Visibility is presentation. Security is access control.

A good Lightning page is designed around work, not metadata inventory. A sales user opening an Opportunity needs a clear view of stage, amount, close date, next step, activities, products, and risk signals. A support user opening a Case needs status, priority, contact, account, entitlement, asset, knowledge, activity, and escalation controls. A manager may need summary components and report charts. The page should make frequent decisions easier.

Dynamic pages can also reduce record type sprawl. If the only difference between two experiences is that a section should appear when a picklist has a certain value, a dynamic field section may solve the problem without another record type. However, if the business needs different picklist values, business processes, defaults, and layout assignments, record types may still be appropriate.

Performance and maintainability are part of UX. A record page crowded with report charts, flows, related lists, rich text, and conditional sections can load slowly or confuse users. Too many visibility rules can be hard to troubleshoot. Use clear naming for pages and components, document assignment logic, and test with sample records that hit each condition.

A practical Dynamic Forms workflow is:

1. Confirm the object and page support the desired dynamic behavior in the target org.
2. Review field-level security before designing visibility rules.
3. Build field sections around user tasks, not around the full field list.
4. Add visibility filters for meaningful conditions such as record type, status, profile, permission, or field values.
5. Configure actions so the most relevant commands appear at the right time.
6. Activate the page at the appropriate org, app, record type, and profile level.
7. Test as target users on desktop and mobile where the team works.

Admins should also think about mobile behavior. A page that works well on a wide desktop may feel crowded on a phone. Related lists, field sections, and action placement can feel different by form factor. If field teams use Salesforce mobile, test the mobile experience before declaring the design complete.

Dynamic Forms can interact with requiredness. A required field that is hidden by visibility logic can create confusing save behavior if not designed carefully. Conditional requirements are often clearer in validation rules with user-friendly messages. If a field becomes required only in a visible section, test create and edit flows for every record type and user group.

Agentforce and AI-assisted experiences add another reason to model and secure fields correctly. A page can guide a human user, but AI grounding and automation still depend on data quality, permissions, and trustworthy field definitions. Do not expose sensitive fields in page components or agent actions just to make an experience feel convenient. Admins should understand what data an agent or prompt can access and test outcomes with realistic permissions.

Exam scenarios usually ask what will solve the stated problem with the least unintended impact. If the problem is clutter, think Lightning page design, Dynamic Forms, Dynamic Actions, and component visibility. If the problem is unauthorized access, think permissions, field-level security, and sharing. If the problem is invalid data, think validation. If the problem is different lifecycle values, think business process and record type.