Master Salesforce Lightning UI: Quick Actions, Dynamic Forms & Page Layouts

💬 In plain words: Buttons and actions are how users get things done on a record. Quick Actions are the native way to do this in Salesforce Lightning. JavaScript buttons are completely dead. Page Layouts still control basic field and related list availability, but the Lightning Record Page handles the overall component structure. Finally, Dynamic Forms takes things to the next level by letting you put individual fields right on the page and hide them based on specific rules.

📌 Real-Life Example: Imagine an older Salesforce org with a custom JavaScript button that recalculates an order total. If you switch to Lightning, clicking it does absolutely nothing. The modern fix? Rebuild it as a Quick Action that launches an auto-launched Flow, a Screen Flow, or a Lightning Web Component (LWC) that calls Apex. The user still clicks a button, but underneath, it uses a supported, modern mechanism.

🗝️ Key Points at a Glance

• JavaScript buttons fail silently in Lightning. Migrate them to Quick Actions.
• Dynamic Forms eliminates the need for dozens of page layouts just to show or hide a few fields.
• Field-Level Security (FLS) always overrides page layouts. If a user lacks FLS, the field is invisible everywhere.
• Global Actions cannot inherit data from the current record, whereas Object-Specific Actions can.
• Dynamic Related Lists now allow you to filter and customize related lists directly from the Lightning App Builder.

📐 The Core Concepts of Lightning UI

To master the Salesforce Lightning user interface, you need to understand how its different layers work together. Let's break them down:

• Quick Actions: This is how you give users a button in Lightning. Object-specific actions live on a single object and inherit that record's context (allowing you to pre-fill fields). Global actions live anywhere, like the global header, and have no record context. Action types include creating records, updating records, logging calls, sending emails, launching Flows, and triggering custom LWCs.
• Page Layouts: These dictate which fields and related lists exist on a specific object and record type. They also determine what fields are read-only or required at the UI level, and drive the Highlights Panel via the Compact Layout.
• Lightning Record Pages: Built using the Lightning App Builder, this layer controls the layout of components (tabs, related lists, standard components, custom LWCs). You assign these pages by App, Record Type, and Profile.
• Dynamic Forms: This feature revolutionizes page layouts. It allows you to drag individual fields and field sections directly onto the Lightning Record Page. You can then apply visibility rules so a field only shows up when certain conditions are met, drastically reducing the need for multiple record types. (Update: Dynamic Forms is now supported on most standard objects like Account, Contact, Opportunity, Lead, and Case!)
• List Views: Saved filters over an object that display specific columns. They support mass actions, inline editing, and List View Buttons. Search Layouts dictate which buttons and columns appear here.

🧠 The UI Layer Cake: Page Layout = Available Fields & Lists. Lightning Record Page = Component Layout. Dynamic Forms = Conditional Field Placement.

🧭 360 Card: Buttons, Actions & Layouts

Rule: Quick Actions are the standard way to build buttons in Lightning.
Gain: A single action can launch a Flow, an LWC, or a form, and works flawlessly across desktop and the mobile app.
Price: Migrating legacy JavaScript buttons requires manual rebuilding and analysis.
Limits: Global actions cannot pre-fill data from a specific record. Only Object-specific actions can.
Pro-Tip: Before Dynamic Forms, hiding a field conditionally required creating a new Record Type and Page Layout. Now, it's just a simple filter rule on the Lightning Page.

⚠ INTERVIEW TRAP: If asked about JavaScript buttons in Lightning, remember: they do not throw a visible error. They fail silently and do absolutely nothing. Every single one must be converted into a Quick Action, URL button, or LWC.

💡 Core Q&A: Real-World Scenarios

Q: An org migrating to Lightning has 40 JavaScript buttons that no longer work. What are your options, and how do you fix them?

🎯 Say this first: "JavaScript buttons are dead in Lightning. I would audit them, group duplicates, and rebuild them as Quick Actions based on their function."

A: First, clarify that JavaScript buttons fail silently in Lightning. Then, outline the triage process based on what the buttons actually do:

• Navigation: If the button just redirects the user, rebuild it as a standard URL button. It's the cheapest, fastest fix.
• Business Logic / Field Updates: Rebuild it as a Quick Action that launches a Screen Flow or Autolaunched Flow. This keeps the logic declarative and easy to maintain.
• Complex UI / Custom APIs: Build an LWC Quick Action. This is perfect if you need deep customization or need to shape an Apex response.
• List View Mass Operations: Use a List View Button, or shift the workload to a Flow or Batch Apex job.

Senior Developer Tip: Don't just rebuild 1-to-1. Consolidate duplicate buttons and use Dynamic Forms or Record Types to ensure the new Quick Action only appears for the users who actually need it.

Q: A field is on the page layout, but a group of users cannot see it. Where do you look?

A: Always check Field-Level Security (FLS) first. FLS is the ultimate gatekeeper.

• The page layout only decides where a field is placed. It cannot grant access. If FLS hides the field on their Profile or Permission Set, it stays invisible.
• If FLS is correct, check the Record Type. Are they viewing a record type assigned to a different layout?
• Next, check Dynamic Forms. Is there a visibility rule hiding the field based on another field's value?
• Finally, check the Lightning App Builder component itself. Is the entire field section hidden by a component visibility filter?

Rule of thumb: A layout is presentation. FLS is permission. Permission always wins.

Q: Object-specific versus Global Quick Action—what is the real difference, and what is the common trap?

A: The difference comes down to Context.

• An Object-Specific Action is tied to a specific object (like an Account). It carries the $recordId context. Because of this, it can pre-fill fields automatically (e.g., creating a Contact automatically linked to the Account you are viewing).
• A Global Action lives anywhere (like the top navigation bar). It has absolutely zero record context. It simply creates standalone records.

The Trap: Developers sometimes put a Global Action on a Lightning Record Page and wonder why the parent ID field isn't pre-populating. It can't. If the action needs data from the screen the user is looking at, it must be an Object-Specific Action.

Q: Page Layout, Lightning Record Page, and Dynamic Forms seem to overlap. Who controls what now?

A: They are three distinct layers that stack on top of each other:

• Page Layout: Historically controlled everything. Today, it still acts as the foundation for which fields and related lists exist, and drives the Highlights Panel.
• Lightning Record Page: Manages the macro structure. It controls where the components (tabs, related lists, report charts, LWCs) sit on the screen.
• Dynamic Forms: The modern way to handle the micro structure. It lets you peel fields away from the Page Layout and drop them directly into the Lightning Page as individual components, allowing for conditional visibility.

Update Note: With the introduction of Dynamic Related Lists, even related lists are moving away from Page Layouts and directly onto the Lightning Page!

🚀 LWC Real-World Scenario: Complex UI

Q: What is the hardest thing you have built in a Lightning Web Component (LWC)?

A: When answering this in an interview, structure it clearly (Situation, Task, Action, Result). Here is a great blueprint:

• Situation: Built a custom Dispatcher Screen viewing 2,000 live delivery records. It had three separate LWC components communicating on one page.
• Task: Delivery updates from drivers in the field had to appear within seconds without the dispatcher having to refresh the browser, and without locking up the UI.
• Action: Used Platform Events for live server pushes, receiving them via the empApi module. Kept the three components in sync using Lightning Message Service (LMS). Implemented Optimistic UI to show changes instantly, reconciling with refreshApex() when the server confirmed.
• The Hardest Part: Handling duplicate events when a tab remounted and subscribed twice. Fixed this by strictly un-subscribing in disconnectedCallback() and maintaining a processed-ID set.
• Result: Updates rendered in under 3 seconds. Page performance increased drastically.

📝 2-Minute Self-Check

• Q1. You need to display and edit a single record with zero custom Apex code. What LWC tag do you use?
  A1. Use lightning-record-form or lightning-record-edit-form. They handle Field-Level Security and data caching automatically.
• Q2. A user clicks a different record in a console app tab, but your custom LWC still shows the old data. Why?
  A2. Your @wire parameter is missing the $ prefix (e.g., '$recordId'). Without the dollar sign, the wire is not reactive, so it never re-fires when the ID changes.
• Q3. A page makes three independent imperative Apex calls on load, taking 1.5 seconds total. How do you optimize it?
  A3. Use Promise.all(). This fires the calls in parallel, meaning you only wait for the slowest individual call, not the sum of all three.