4.5 Dynamic Forms, Dynamic Actions, and User Experience

Salesforce Admin Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Platform Administrator Orientation and Official Source Control

1.1 Credential Name, Current Outline, and Search Language 1.2 Exam Format, Fee, Score, and Reference Rules 1.3 Trailhead, Trailhead Academy, and Pearson VUE Delivery Workflow 1.4 Domain Weights, Agentforce, and Study Prioritization 1.5 Maintenance Modules, Credential Ethics, and Exam Security 1.6 Developer Edition, Trailhead Playground, and Practice Bank Workflow

2 Chapter 2: Configuration, Setup, User Management, and Org Controls

2.1 Company Information, Fiscal Year, Business Hours, and Locale 2.2 User Records, Licenses, Profiles, Permission Sets, and Login Access 2.3 Login Security, Session Settings, and Identity Basics 2.4 Setup Navigation, Release Readiness, and Change Control 2.5 UI Settings, Home Pages, Apps, and Navigation 2.6 Configuration and Setup Case Lab

3 Chapter 3: Security, Access, Identity, and Sharing Model

3.1 Org-Wide Defaults, Roles, Sharing Rules, and Teams 3.2 Profiles, Permission Sets, Permission Set Groups, and Muting 3.3 Field-Level Security, Page Layouts, and Dynamic Forms 3.4 Record Access Troubleshooting and Login-As Workflow 3.5 Identity, Login History, MFA, and Session Risk 3.6 Data Visibility, Reporting, and Analytics Security 3.7 Security and Access Case Lab

4 Chapter 4: Object Manager, Lightning App Builder, and Data Modeling

4.1 Standard Objects, Custom Objects, and Schema Fit 4.2 Fields, Formulas, Rollups, Validation, and Requiredness 4.3 Lookup, Master-Detail, and Junction Relationships 4.4 Record Types, Business Processes, Page Layouts, and Lightning Pages 4.5 Dynamic Forms, Dynamic Actions, and User Experience 4.6 Schema Change Risk, Data Quality, and Deployment Readiness 4.7 Object Modeling Case Lab

5 Chapter 5: Sales, Marketing, Service, and Support Applications

5.1 Lead, Campaign, Account, Contact, and Opportunity Flow 5.2 Sales Processes, Path, Products, Price Books, and Forecasting 5.3 Case Management, Queues, Assignment, Auto-Response, and Escalation 5.4 Knowledge, Entitlements, Service Console, and Support Productivity 5.5 Sales-Service Data Quality and Automation Boundaries 5.6 Application Configuration Troubleshooting 5.7 Sales and Service Applications Case Lab

6 Chapter 6: Data and Analytics Management

6.1 Data Import Wizard, Data Loader, Export, and Backup 6.2 Duplicate Management, Validation, and Data Quality Controls 6.3 Data Transfer, Ownership, Mass Update, and Mass Delete 6.4 Report Types, Filters, Summary Formulas, and Buckets 6.5 Dashboards, Components, Subscriptions, and Sharing Impact 6.6 Analytics Security, Visibility, and Executive Reporting 6.7 Data and Analytics Case Lab

7 Chapter 7: Automation, Flow, Approval, and Operational Processes

7.1 Automation Tool Selection and Order of Execution 7.2 Flow Builder: Screen, Record-Triggered, Scheduled, and Autolaunched Flows 7.3 Approval Processes, Email Alerts, and Notification Patterns 7.4 Validation Rules, Assignment Rules, and Escalation Rules 7.5 Automation Testing, Debugging, and Governance 7.6 Automation Performance, Recursion, and Maintainability 7.7 Automation Case Lab

8 Chapter 8: Productivity, Collaboration, Mobile, and AppExchange

8.1 Activities, Tasks, Events, Calendar, and Email Productivity 8.2 Chatter, Feeds, Groups, Notifications, and Collaboration Governance 8.3 Salesforce Mobile Navigation, Actions, and Page Design 8.4 List Views, Kanban, Path, and User Adoption Tools 8.5 AppExchange Evaluation, Installation, Permissions, and Risk 8.6 Productivity and Collaboration Case Lab

9 Chapter 9: Agentforce for Platform Administrators

9.1 Agentforce Use Cases, Admin Boundaries, and Fit 9.2 Trusted AI, Security, Data Access, and Permission Implications 9.3 Agent Builder, Prompt Builder, and Grounding Concepts 9.4 Testing, Deployment, Monitoring, and Feedback Workflows 9.5 Agentforce Service, Sales, and Internal Productivity Scenarios 9.6 Agentforce Risk, Troubleshooting, and Governance 9.7 Agentforce Case Lab

10 Chapter 10: Integrated Salesforce Admin Scenario Labs

10.1 New Sales Org Setup Integrated Lab 10.2 Service Team Case Management Integrated Lab 10.3 Data Quality and Analytics Integrated Lab 10.4 Security, Access, and Reporting Integrated Lab 10.5 Flow Automation and Change Control Integrated Lab 10.6 Agentforce and Adoption Integrated Lab 10.7 Full Admin Simulation Strategy

11 Chapter 11: Final Review, Maintenance, and Test-Day Strategy

11.1 Final 30-Day Salesforce Admin Review Plan 11.2 Trailhead Playground Hands-On Drill Plan 11.3 105-Minute Exam Timing, Flagging, and Review Workflow 11.4 Test-Day Checklist: Online or Test Center 11.5 Post-Exam Maintenance Modules and Next Certifications 11.6 Salesforce Admin Final Mixed Review

4.5 Dynamic Forms, Dynamic Actions, and User Experience

Key Takeaways Explain This Topic AI

Dynamic Forms move field sections onto Lightning record pages so admins can control field placement and visibility with more precision.

Dynamic Actions let admins tailor visible actions based on context, but they do not grant permissions a user lacks.

Component visibility improves usability, but it is not a substitute for object permissions, field-level security, sharing, or validation rules.

Good Lightning page UX reduces noise, supports the user's next action, and is tested across app, profile, record type, and form factor.

Last updated: May 2026

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.

Feature Best use Important limit

Dynamic Forms Place and conditionally show fields and sections on a record page Availability can vary by object and release, so verify in the target org.

Dynamic Actions Tailor visible actions to record and user context Does not grant permissions or bypass validation.

Component visibility Show components only when useful Does not secure data by itself.

Field-level security Protect field visibility and editability Does not design the page experience.

Validation rules Enforce data quality on save Does not decide where fields appear.

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:

Confirm the object and page support the desired dynamic behavior in the target org.

Review field-level security before designing visibility rules.

Build field sections around user tasks, not around the full field list.

Add visibility filters for meaningful conditions such as record type, status, profile, permission, or field values.

Configure actions so the most relevant commands appear at the right time.

Activate the page at the appropriate org, app, record type, and profile level.

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.