9.2 Dynamic Actions & Page Interaction Patterns

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

1. 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.
2. 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'.
3. 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.
4. Device Form Factor: Control whether an action appears on Desktop, Phone, or both.

---

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

---

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.