The User Interface (UI) in Salesforce is designed to make interactions with data intuitive and customizable for different user roles. This section focuses on configuring the layout, structure, and tools available for records and apps in Salesforce.
Field Visibility:
Different Layouts for Different Roles:
Custom Picklist Values:
Specific Field Visibility:
Drag-and-Drop Customization:
Embed Components:
Object-Specific Quick Actions:
Global Quick Actions:
| Feature | What It Does | Use Cases |
|---|---|---|
| Page Layouts | Controls the display of fields, buttons, and related lists. | Customize layouts for different roles (e.g., sales reps vs. managers). |
| Record Types | Differentiates record categories for specific business needs. | Tailor picklists and layouts for product lines, processes, or user profiles. |
| Lightning App Builder | Drag-and-drop tool for creating custom app pages. | Build dynamic home pages, app pages, and record pages with embedded reports and components. |
| Quick Actions | Adds buttons for common tasks. | Create shortcuts for tasks like logging calls, updating statuses, or creating records. |
Experiment with Page Layouts:
Create a Record Type:
Build a Page with Lightning App Builder:
Set Up a Quick Action:
User Interface (UI) in Salesforce is designed to enhance user experience by providing intuitive, customizable layouts and actions.
Page Layouts control how fields, actions, and related lists appear on a record page. They help define the UI experience for users based on their role and profile.
Actions: These are buttons such as "New Task", "Send Email", and "Log a Call" that can be added to a Page Layout.
Related Lists: These display related records on an object’s record page.
| Feature | Page Layouts | Lightning Record Pages |
|---|---|---|
| Supported UI | Classic UI & Lightning | Lightning Only |
| Controls | Fields, buttons, related lists | Components, dynamic fields, layouts |
| Custom Components? | No | Yes |
| User-Specific Customization? | Limited to different Page Layouts | Dynamic Forms, Dynamic Actions |
| Best For | Standard field & button control | Custom UI with enhanced flexibility |
Key Takeaway: Use Page Layouts for basic field and button control, while Lightning Record Pages provide advanced UI customization with dynamic visibility settings.
Record Types allow different variations of a record within the same object, enabling customized layouts, picklist values, and business processes.
| Scenario | Use Record Types | Use Page Layouts |
|---|---|---|
| Different business processes (e.g., Retail Sales vs. Enterprise Sales) | Yes | No |
| Different field requirements based on department (e.g., HR vs. Finance) | Yes | No |
| Same business process, different UI layout for different roles | No | Yes |
Lightning App Builder allows users to create customized pages in Lightning Experience using drag-and-drop components.
Dynamic Forms:
Dynamic Actions:
| Feature | Lightning Record Page | Page Layout |
|---|---|---|
| Field Visibility Control | Yes (Dynamic Forms) | No |
| Button Visibility Control | Yes (Dynamic Actions) | No |
| Supports Custom UI Components? | Yes | No |
| When to Use? | Advanced UI customization | Standard field layout |
Best Practice:
Quick Actions improve efficiency by providing shortcuts for users to perform frequent actions.
| Feature | Quick Actions | Custom Buttons |
|---|---|---|
| Purpose | Standard UI actions (e.g., create/update records) | Custom navigation or external API calls |
| Visibility | Can be added to Page Layouts & Global Actions | Placed on related lists, detail pages, or custom components |
| Customization | Form-based UI | Can execute JavaScript, Apex, or Visualforce |
The additional concepts covered in this section refine our understanding of User Interface customization in Salesforce:
Why do fields behave differently on view pages versus New/Edit when using Dynamic Forms?
Because Dynamic Forms and page layouts do not control exactly the same UI surfaces. On Dynamic Forms-enabled pages, fields and sections can be arranged in Lightning App Builder, but New/Edit behavior can still depend on layout and action context.
This is one of the most common Lightning UI troubleshooting themes. Salesforce documentation explains that on Dynamic Forms-enabled pages, fields can be placed on the Lightning page, while the page layout still defines which fields are available in certain contexts. Community questions show the confusion that follows: a record page may look correct in view mode but behave differently in New or Edit because those experiences are not governed by the same setup choices. On the exam, when the requirement is about flexible record-page field placement and conditional visibility, Dynamic Forms is attractive. But when the requirement is specifically about action layout or data-entry layout, page layout and action configuration still matter. A common mistake is assuming Dynamic Forms fully replaces all page-layout behavior everywhere.
Demand Score: 89
Exam Relevance Score: 92
When should I use Lightning App Builder instead of only editing the page layout?
Use Lightning App Builder when you need component-based page design, conditional visibility, and richer Lightning record-page control. Use page layout when you are controlling the traditional field/layout foundation that Lightning still references in some contexts.
The exam often tests whether you understand that Lightning pages and page layouts are related but not identical. Lightning App Builder controls the component-based record page experience and supports features like Dynamic Forms and Dynamic Actions. Page layouts still matter because they define field availability and continue to influence some actions and standard behaviors. That is why admins can make a change in one place and not see the effect they expected somewhere else. In scenario questions, choose Lightning App Builder when the need is personalized Lightning experience, components, tabs, visibility filters, or page composition. Choose page layout when the need is core field arrangement or action/layout behavior still rooted in layout metadata. The trap is believing one tool has completely replaced the other.
Demand Score: 83
Exam Relevance Score: 90
If a field is visible in Lightning but not on the page layout, what should I check first?
Check whether the field is being surfaced by the Lightning page or Dynamic Forms, then verify field-level security and any permission-set access. Do not assume page layout is the only source of field visibility in Lightning Experience.
Community troubleshooting shows this is a frequent admin surprise. In Lightning Experience, visibility can come from the Lightning page configuration, not just the classic page layout mental model. Dynamic Forms increases that separation by letting fields be placed directly on the page. But even then, field-level security still governs whether users can actually access the field. That means a visibility problem can have multiple causes: the field is on the page but hidden by FLS, or not on the layout but shown by the Lightning page, or surfaced through a different component entirely. On the exam, when a question asks how to hide or reveal fields for certain users, remember that UI placement and security are separate layers. A common mistake is trying to solve a security problem only by editing the page layout.
Demand Score: 80
Exam Relevance Score: 88
What usually goes wrong when a Dynamic Forms page works in one org but not after deployment?
The deployed metadata is often incomplete, the Lightning page assignment is missing, or dependencies such as referenced fields/components are not aligned in the target org.
Real-world deployment questions show that Lightning pages are not just “field changes.” The page definition, assignments, dependent components, and referenced metadata all need to line up in the target environment. Salesforce’s change set guidance also emphasizes deploying dependent components. In practice, a page may validate poorly if it references fields or managed-package metadata that the target org cannot resolve, or it may deploy but still show the standard layout because the proper page activation or assignment did not move with it. On the exam, the safest recommendation is to validate dependencies, confirm target-org readiness, and verify page activation/assignment after deployment. The common mistake is assuming that moving the page file alone is enough.
Demand Score: 77
Exam Relevance Score: 85