Study guide
9.2 Dynamic Actions & Page Interaction Patterns
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
9.2 Dynamic Actions & Page Interaction Patterns
Key Takeaways Explain This Topic AI
Dynamic Actions decouple action buttons (Standard, Custom, and Quick Actions) from monolithic Page Layouts, allowing administrators to manage and configure actions directly within Lightning App Builder.
Action visibility rules can be applied to individual buttons in the Highlights Panel or custom page regions based on record field values, user attributes ( $User ), and custom permissions ( $Permission ).
Enabling Dynamic Actions on a Highlights Panel creates an independent action configuration for that Lightning page, overriding the action list defined on the underlying object page layout.
Generally available Dynamic Actions configure the Highlights Panel. For guided controls inside a tab, use supported Flow/components; Dynamic Actions Bar is a separate, restricted pilot.
Dynamic Actions reduce cognitive clutter by presenting users with only the buttons relevant to the current record state, role, and operational context.
Last updated: October 2026
9.2 Dynamic Actions & Page Interaction Patterns
In standard Salesforce deployments, action buttons—such as Edit , Delete , Clone , Log a Call , and custom Quick Actions—are configured within the "Salesforce Mobile and Lightning Experience Actions" section of a traditional Page Layout. This legacy structure suffers from the exact same architectural limitation as legacy field layouts: the configured action list is static by record status; permissions still govern availability , regardless of the record's current lifecycle stage or the user's immediate role.
Under this static model, an Opportunity in the "Closed Won" stage displays the exact same "Submit for Approval" and "Change Stage" buttons as an Opportunity in "Qualification". A tier-1 customer service agent sees the "Escalate to Tier 3" and "Issue Executive Credit" buttons even when company policy strictly forbids them from using those functions. To hide inappropriate buttons, organizations historically created duplicate page layouts, introducing immense maintenance overhead.
Dynamic Actions resolves this challenge. By moving action management directly into Lightning App Builder , App Builders can configure, reorder, and conditionally display individual action buttons on the Highlights Panel and throughout custom page regions.
Dynamic Actions Architecture & Placement
Use generally available Highlights Panel actions first. The additional Actions Bar surface below is a separate pilot and must not be assumed available:
1. The Highlights Panel Component
The Highlights Panel sits at the top of most standard Lightning record pages. When an administrator clicks the Highlights Panel in Lightning App Builder, a toggle option labeled Enable Dynamic Actions appears in the properties pane:
Toggling this setting on decouples the Highlights Panel from the legacy Page Layout's action list.
Administrators can migrate existing actions from the Page Layout or build a clean action list from scratch.
Each action in the list becomes an independently configurable entity with its own label, icon, and visibility logic.
2. Custom Page Regions (Dynamic Actions Bar Pilot)
Dynamic Actions is not restricted to the top Highlights Panel. The Dynamic Actions Bar is a pilot , available to selected customers by agreement. It supports global actions on Lightning Experience desktop record and app pages; it is not a generally available container for arbitrary object-specific quick actions:
Place a Dynamic Actions Bar inside a "Billing & Invoicing" sub-tab containing only "Generate Invoice" and "Process Payment" actions.
Place a Dynamic Actions Bar inside a "Technical Support" accordion pane containing "Escalate Case" and "Request Diagnostics".
This contextual placement prevents users from having to scroll back to the top of long record pages to trigger workflows related to specific sub-tabs. [Legacy Action Architecture]
- Page Layout: Salesforce Mobile & Lightning Actions Section
- └── Static list: [Edit] [Delete] [Clone] [Submit for Approval] [Discount Override] [Close Case]
└── Layout list is static by record status; permissions still affect available actions.
- [Dynamic Actions Architecture]
- Highlights Panel (Dynamic Actions Enabled)
- ├── [Edit] (Always visible)
- ├── [Submit for Approval] (Visible ONLY if Status = 'Draft' AND Amount > $50,000)
- └── [Discount Override] (Visible ONLY if $Permission.Can_Override_Discounts = TRUE)
- Custom Sub-Tab: "Logistics & Shipping"
- └── Dynamic Actions Bar Component
- ├── [Generate Bill of Lading] (Visible if Order_Status = 'Approved')
- └── [Schedule Freight Pickup] (Visible if Ready_for_Dispatch = TRUE)
- Action Visibility Rules & Filter Criteria
Similar to Dynamic Forms, Dynamic Actions allows administrators to establish fine-grained conditional visibility filters on every individual action button. An action only renders in the user interface when all filter conditions evaluate to TRUE .
Filter Contexts
Record Field Filters : Base action visibility on the record's current state:
Show Submit for Approval only when Approval_Status__c = 'Pending Submission' .
Show Reopen Case only when IsClosed = TRUE .
Show Generate Contract only when StageName = 'Negotiation/Review' and Amount > 0 .
User Context Filters ( $User ) : Base action visibility on the current user's profile, role, or department:
Show Delete Account only when $User.Profile.Name = 'System Administrator' .
Show Assign Territory only when $User.Department = 'Sales Operations' .
Permission Context Filters ( $Permission ) : Base action visibility on Custom Permissions assigned via Permission Sets:
Show Override Credit Limit only when $Permission.Credit_Override_Authorized = TRUE .
Show VIP Customer Escalation only when $Permission.Tier_3_Agent = TRUE .
Device Form Factor : Control whether an action appears on Desktop , Phone , or both.
Tip
The Power of State-Aware Action Lifecycles: Instead of showing all possible lifecycle actions simultaneously, configure actions to appear sequentially. For example, on a custom Onboarding record: Step 1 shows only "Complete Background Check". Once completed, that button disappears and "Issue Equipment" appears. Once equipment is issued, "Finalize Orientation" appears. This guides users through complex processes without procedural documentation.
Button Display Mechanics & Overflow Menus
In the desktop Highlights Panel, screen real estate determines how many action buttons render as visible buttons versus collapsing into the dropdown menu:
Administrators can configure the Number of Visible Actions (typically between 3 and 5 actions on standard desktop screens).
The first 3 to 5 actions configured in the Dynamic Actions list render as direct buttons on the Highlights Panel.
Any additional actions beyond that threshold automatically collapse into the Overflow Menu (the right-hand dropdown arrow ▾ ).
Administrators can drag and reorder actions in Lightning App Builder to ensure high-frequency actions occupy the direct button slots while secondary actions reside in the overflow menu.
Page Layout Actions vs. Lightning App Builder Dynamic Actions
- Feature Traditional Page Layout Actions Dynamic Actions in Lightning App Builder
- Management Location Setup > Object Manager > Page Layouts Setup > Lightning App Builder
- Conditional Visibility Not supported (static display) Supported per action button
- Filter Criteria None (all or nothing per layout) Record fields, $User , $Permission , Device
Placement Flexibility Strictly top header and mobile bottom bar Highlights Panel; use supported embedded controls elsewhere (Actions Bar is pilot)
Configuration Scope Tied to Page Layout metadata Tied to specific Lightning Record Page
Administrative Overhead High; requires multiple layouts to vary buttons Low; single page handles all button permutations
Exam Traps and Best Practices
Trap: The Disappearing Action Dilemma. When an administrator enables Dynamic Actions on an existing Highlights Panel for the first time, selecting "Start from Scratch" clears all existing actions! Users will immediately report that standard actions like "Edit" and "Delete" have vanished. Always choose Migrate from Page Layout during the initial enablement to copy established actions before pruning.
Trap: Action Visibility Is Not Security. Hiding the "Delete" action button on the Highlights Panel using a conditional visibility rule prevents the user from clicking Delete in that record's header. However, if that user possesses Delete CRED permission on the object, they can still delete the record via List Views , Mass Delete tools , Developer Console , or the REST/SOAP API . Always enforce data security at the object/field level rather than relying on action visibility.
Trap: Overlooking Dynamic Actions on Mobile. Dynamic Actions on mobile must be enabled in Setup ( Salesforce Mobile App Setup > Dynamic Actions on Mobile ). Furthermore, when configuring actions in App Builder, verify whether actions are set for Desktop, Phone, or both.
Best Practice: Decouple Action Entitlement with Custom Permissions. Avoid filtering action buttons by $User.Profile.Name . Profiles change frequently during organizational restructurings. Utilizing $Permission.Custom_Permission_Name allows administrators to grant or revoke button visibility dynamically across users simply by assigning or removing a Permission Set.
Official Source Check
Checked October 19, 2026: Standard components and Dynamic Actions Bar pilot .