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.