Dynamic Actions

Why Dynamic Actions Matter

For years, Salesforce administrators controlled which buttons and quick actions appeared on a record by editing the page layout. If different users or different record states needed different actions, the only option was to create more page layouts, more record types, and more profile-to-layout assignments. That approach is rigid, hard to maintain, and quickly leads to 'layout sprawl'. Dynamic Actions solve this problem by letting you assign actions directly on the Lightning record page and show or hide each one with visibility rules. For the Advanced Administrator exam, Dynamic Actions sit squarely in the Advanced Objects and Applications domain, and you are expected to know when to recommend them, how they are configured, and how they differ from older techniques such as page layout assignments.

What Are Dynamic Actions?

Dynamic Actions are a Lightning App Builder feature that moves the management of record page actions (quick actions, standard buttons, custom buttons, and Lightning component actions) from the page layout to the Lightning record page itself. When you enable Dynamic Actions on the Highlights Panel component of a record page, the actions defined on the page layout are ignored for that page, and the actions you add in App Builder take over. Each action can then be given visibility rules, so the button appears only when specific conditions are met, for example only when a Case Status is not Closed, only for users with a certain custom permission, or only on a phone.

Think of it this way: Dynamic Forms control which fields appear on a record page and when, while Dynamic Actions control which buttons and actions appear and when. Both are part of Salesforce's effort to make the Lightning record page itself the single place to configure the user experience.

Key Facts to Memorize

1. Dynamic Actions are configured in the Lightning App Builder, not in Setup under Page Layouts.
2. On desktop record pages, you enable them on the Highlights Panel component by selecting Enable Dynamic Actions (the option used to be labelled 'Upgrade Now' and allows you to migrate existing page layout actions into the page).
3. Once enabled, the actions from the page layout are no longer used for that record page. You must add actions in App Builder.
4. Each action can have visibility rules built from filters. Filters can reference record field values, device/form factor, user record fields (via $User), and permissions (via $Permission), among other options.
5. Filters are combined with AND logic by default, and you can also create custom filter logic. Up to 10 filter conditions can be applied to a single action.
6. Dynamic Actions are supported on custom objects and on many standard objects such as Account, Case, Contact, Lead, and Opportunity (support for standard objects has expanded over releases).
7. Dynamic Actions are available for both the desktop and phone form factors. You can build one page that shows different actions on mobile and desktop by using the Device filter.
8. There is also a Dynamic Actions Bar component that can be placed on app pages and Home pages, giving you action buttons with visibility rules outside of record pages.
9. Hiding an action with a visibility rule is a user experience control, not a security control. If a user has permission to perform the underlying operation, they could still do so another way. Object permissions, field-level security, and validation rules remain the real security layer.

How Dynamic Actions Work Step by Step

Step 1: Open the record page in Lightning App Builder. Navigate to the object's Lightning Record Pages (or click the gear icon on a record and choose Edit Page).

Step 2: Select the Highlights Panel component. In the properties pane you will see the option to enable Dynamic Actions. If the page layout already contains actions, Salesforce offers to migrate them so you do not start from scratch.

Step 3: Add actions. Click Add Action and choose from the available quick actions, standard buttons, custom buttons, and Lightning component actions for that object. You can reorder them by dragging. The first few actions display as buttons and the rest collapse into an overflow menu.

Step 4: Add visibility rules. Select an action and click Add Filter. Choose a filter type: Record Field (for example Stage equals Closed Won), Device (Desktop or Phone), or Advanced (for example $User.Profile.Name or $Permission.CustomPermission). Build one or more conditions and, if needed, set custom filter logic such as 1 AND (2 OR 3).

Step 5: Save and activate. As with any Lightning page, activation determines whether the page is the org default, app default, or assigned to specific app, record type, and profile combinations. Visibility rules then operate at run time, evaluating conditions as the user views the record. If a field value changes and the record refreshes, the actions re-evaluate.

Practical Scenarios

Scenario A: Stage-dependent buttons. A sales manager wants the 'Request Discount Approval' quick action to appear only when Opportunity Amount is greater than 50,000 and Stage is Negotiation. Rather than cloning layouts, enable Dynamic Actions and add two Record Field filters on that action.

Scenario B: Mobile versus desktop. Field technicians using the mobile app need a 'Log Site Visit' action, but office staff on desktop should not see it. Use a Device filter on the action so it displays only on Phone.

Scenario C: Role-based actions without new layouts. Only users with a custom permission 'Can Escalate Cases' should see the 'Escalate' button. Create a custom permission, assign it through a permission set, and add an Advanced filter using $Permission on the action.

Scenario D: Reducing layout count. An org has eight Account page layouts that differ only by which buttons appear. Consolidating to one Lightning record page with Dynamic Actions and visibility rules reduces maintenance dramatically.

Dynamic Actions Compared to Alternatives

Page layout actions: static, assigned by profile and record type, cannot respond to field values or device. Still used when Dynamic Actions are not enabled.
Record types and layout assignments: useful for genuinely different business processes, but overkill when the only difference is a button.
Dynamic Forms: controls fields and sections, not buttons. Often used together with Dynamic Actions.
Component visibility on the record page: shows or hides entire components; Dynamic Actions apply the same filter concept to individual buttons.
Flow or Apex: can perform logic, but do not by themselves control whether a button appears.

Limitations and Gotchas

Dynamic Actions must be enabled per record page; enabling them on one page does not affect other pages for the same object. Classic page layouts continue to govern Salesforce Classic and any Lightning page where Dynamic Actions are not enabled. Some action types that rely on Classic behaviours (for example certain custom buttons configured to display in a new window) may behave differently in Lightning. Visibility rules are evaluated when the page loads or refreshes, so an action does not disappear the instant a field is edited inline until the record view refreshes. Finally, the Dynamic Actions Bar on app and Home pages supports global actions and object-specific actions differently, so read scenario details carefully.

Exam Tips: Answering Questions on Dynamic Actions

1. Spot the trigger phrases. When a question mentions 'show a button only when', 'based on a field value', 'different actions on mobile', 'without creating additional page layouts', or 'reduce the number of page layouts', the answer is almost always Dynamic Actions.

2. Know where configuration happens. If an answer choice says to edit the page layout to make an action conditional, it is wrong. Conditional actions are configured in Lightning App Builder on the Highlights Panel (or the Dynamic Actions Bar).

3. Distinguish Dynamic Actions from Dynamic Forms. Fields and sections equal Dynamic Forms; buttons and quick actions equal Dynamic Actions. Questions frequently include both as distractors.

4. Remember the filter types. Record Field, Device, and Advanced ($User, $Permission). If the scenario mentions a custom permission, think $Permission filter. If it mentions phone users, think Device filter.

5. Do not confuse visibility with security. If a question asks how to prevent a user from performing an action, the correct answer involves object permissions, field-level security, sharing, or validation rules, not a visibility rule. If it asks how to simplify the interface or reduce clutter, visibility rules are appropriate.

6. Watch for standard versus custom object details. Older exam material stated Dynamic Actions were limited to custom objects on desktop. Current behaviour supports many standard objects. If the question is clearly about a supported standard object like Account or Case, Dynamic Actions is a valid recommendation.

7. Prefer declarative, low-maintenance solutions. The Advanced Administrator exam rewards answers that minimise technical debt. Given a choice between creating three new record types and page layouts versus one page with Dynamic Actions, choose Dynamic Actions.

8. Remember the migration behaviour. Enabling Dynamic Actions lets you migrate existing layout actions, and afterwards the page layout actions are ignored for that page. A question might ask why a button 'disappeared' after enabling the feature: the answer is that the layout actions are no longer used and the action must be added in App Builder.

9. Eliminate code-based distractors. Apex, Visualforce, or custom Lightning components that hide buttons are rarely the best answer when a declarative feature exists.

10. Read for form factor and page type. If the scenario involves a Home page or app page rather than a record page, the Dynamic Actions Bar component is the relevant feature.

Summary

Dynamic Actions let administrators control record page buttons and quick actions in Lightning App Builder, applying visibility rules based on record fields, device, user attributes, and permissions. They replace the need for multiple page layouts whose only difference is which actions appear, work across desktop and mobile, and pair naturally with Dynamic Forms. For the exam, recognise the scenario cues, remember that configuration lives on the Highlights Panel in App Builder, keep the distinction between visibility and security clear, and always favour the declarative, low-maintenance option.