Action Layout
An Action Layout controls which fields appear inside a single quick action and how they are ordered when a user invokes that action from a record.
Definition
An Action Layout controls which fields appear inside a single quick action and how they are ordered when a user invokes that action from a record. It is the per-action equivalent of a page layout. When an admin creates a Create-a-Task quick action on Account, the Action Layout decides which Task fields the user sees in the popup, which are required, and in what order. The Action Layout is distinct from the Lightning Page Layout (which decides where the action button itself appears on the record).
Action Layouts exist because quick actions are essentially mini record-create or mini record-update forms inside a popup. Without per-action control over the fields shown, every action would inherit the full object's page layout, which is usually overwhelming for a quick task. Action Layouts let admins surface only the fields the action needs (Subject, Due Date, Comments for a Create-a-Task action) and skip the dozens of other Task fields that would clutter the popup.
Why the Action Layout is what makes quick actions actually quick
Where Action Layouts live in setup
Object Manager, pick the object, Buttons, Links, and Actions. Each quick action listed has a Layout column with an Edit link. Clicking through opens the Action Layout editor, which looks like a stripped-down page layout editor: a palette of available fields on the left, the action's current layout in the middle, drag to add or remove. The layout is per-quick-action, not per-object. The Create-a-Task action on Account has its own layout; the Create-a-Task action on Opportunity has its own separately.
Quick actions, page layouts, and the publisher
Three things together produce the action experience users see. The quick action definition (what kind of action, what object, what record type). The Action Layout (which fields appear inside the popup). The Lightning Page Layout's Actions section (which actions appear on the record page). Changing the Action Layout updates the popup; changing the Page Layout's Actions section adds or removes the button on the record. Admins regularly confuse the two; "the field is missing from my action" usually means Action Layout, while "the action button does not show on the record" usually means Page Layout.
Field selection and the field-set discipline
An Action Layout should include only the fields the user must fill in to complete the action. A Create-a-Task action usually needs Subject, Due Date, Assigned To, and Comments. Adding 15 more Task fields turns the popup into a full record-create form and defeats the point of a quick action. The discipline: ask "what is the minimum the user must enter for this action to be useful" and resist adding the rest. Required fields with default values (Status, Type) belong in predefined values on the action definition, not in the Action Layout.
Predefined values and the layout interaction
The quick action definition supports predefined field values that are set automatically when the action is invoked. A Create-a-Task action on Opportunity can predefine Subject as "Follow up on opportunity" and Related To as the Opportunity ID. Predefined values do not need to appear in the Action Layout; they are set behind the scenes. This pattern keeps the layout short. The user sees the three fields they need to fill in; the platform sets the seven defaults automatically. Most admins underuse predefined values and end up with action layouts longer than they should be.
Required fields and validation
Fields can be marked required on the Action Layout independently of whether they are required at the object level. A field that is optional on the Task object can be required for this specific action through the Action Layout. The reverse does not work; a field required at the object level is required in the action regardless of the Action Layout setting. Validation rules on the underlying object still apply; an action that violates a validation rule shows the rule's error message and blocks save. Plan validation rule coverage for action-driven creates the same way you plan for direct record-creates.
Mobile considerations and the small-screen reality
Quick actions are the primary way mobile users create records, log activities, and update fields. The Action Layout determines the mobile experience directly; a popup with 15 fields is unusable on a phone. Mobile-first orgs keep Action Layouts to 5 fields or fewer for any action invoked frequently in the field. The Salesforce Mobile App respects the Action Layout exactly; what you configure in the desktop editor is what the mobile user sees in the popup. Test mobile experience by previewing the action on a small viewport before declaring the layout done.
Object record types and per-record-type layouts
When an object has multiple record types, each record type can have its own Action Layout for the same quick action. A Create-a-Case action on a Service Cloud org with B2B and B2C record types can show different fields per record type. The configuration is per record type, set in the quick action page layout assignments. This adds complexity but matches reality; B2B cases need Account and Contract fields, B2C cases need Customer Email and Channel. Without per-record-type Action Layouts, the action becomes the lowest common denominator and feels generic.
How to design Action Layouts that keep quick actions quick
The successful pattern: define the minimum field set the action needs, use predefined values for everything else, keep the layout under 7 fields, validate on mobile before shipping. The failed pattern: drag every field onto the layout "in case the user needs it" and produce a popup nobody uses.
- Define the quick action first
Object Manager, pick the object, Buttons, Links, and Actions, New Action. Pick the action type (Create a Record, Update a Record, Log a Call, Send Email). Save before opening the layout editor.
- Identify the minimum field set
Ask the user: what is the smallest set of fields you must enter for this action to be useful? Resist the urge to add fields "in case." Three to five fields is usually right for quick actions.
- Configure predefined values on the action definition
For fields the action should set automatically (Status, Type, Related To), use predefined values rather than adding them to the layout. The user does not see them; the platform sets them.
- Open the Action Layout editor and add only the chosen fields
Drag the minimum field set onto the layout. Mark each as required or optional explicitly. Order them in the sequence the user will fill them.
- Test the action from a real record
Open a record of the object type, click the action button, fill it out as a user would. Confirm the field set is right, required fields enforce correctly, validation rules behave as expected.
- Test the action on a mobile viewport
Open the action on a phone-sized window or actual mobile device. Five fields fit; ten fields do not. Adjust the layout if mobile usage is a real workflow.
- Configure per-record-type layouts if the object has multiple
For multi-record-type objects, set per-record-type Action Layouts so each record type gets the right field set. The configuration lives in the action's page layout assignments.
Which fields appear in the action popup. Three to five is the sweet spot for quick actions.
Whether each field is required for this specific action. Independent of object-level required setting.
Top-to-bottom sequence the user fills in. Should match the user's natural thought process.
Different Action Layouts per record type when the object has multiple. Adds complexity but matches reality.
Quick actions are the primary mobile experience for create and update. Preview at phone size before declaring done.
- Action Layout and Page Layout are different concepts. Action Layout controls the popup field set; Page Layout controls where the action button appears on the record. Most admin confusion traces to mixing these up.
- Predefined values are easy to overlook. Many overly long Action Layouts could be shorter by moving fields to predefined values on the action definition.
- Required fields at the object level cannot be made optional in the Action Layout. The action will block save until the field has a value regardless.
- Mobile experience is direct. A popup with 15 fields is unusable on a phone; the Action Layout you ship to desktop is the one mobile users see.
- Per-record-type Action Layouts add real value but also real complexity. Configure deliberately and document so the team knows which record type uses which variant.
Trust & references
Cross-checked against the following references.
- Action Layouts referenceSalesforce
- Quick Actions overviewSalesforce
Straight from the source - Salesforce's reference material on Action Layout.
- Quick Actions OverviewSalesforce Help
- Customize Action LayoutsSalesforce Help
- Create Object-Specific Quick ActionsSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is the primary benefit of Action Layout for Salesforce administrators?
Q2. In which area of Salesforce would you typically find Action Layout?
Q3. Why is understanding Action Layout important for Salesforce admins?
Discussion
Loading discussion…