Explanation:

The Lightning App Builder is a point-and-click tool that allows administrators to create custom, responsive pages for both desktop and mobile experiences in Salesforce.
The two primary types of pages that can be customized for the Salesforce Mobile App are:

C. App Page (✅ Correct)
An App Page is a custom page that serves as a landing or workspace page in the Salesforce app.
You can use it to display important information, dashboards, lists, or custom components that are most relevant to your mobile users.

For example:
- A Sales Dashboard Page for mobile users
- A Technician Overview Page showing service appointments and maps

App pages are available in both Lightning Experience (desktop) and the Salesforce Mobile App.

D. Record Page (✅ Correct)
A Record Page is a custom layout that appears when users view a record (like an Account, Contact, or Opportunity).
With Lightning App Builder, admins can design different record pages for mobile and desktop users — showing relevant components depending on the device.

For example:
- A simplified mobile record page showing key fields and related lists for quick viewing on the go
- A detailed desktop page for full record management

❌ Incorrect Options:
A. User Page:
There is no such thing as a “User Page” type in Lightning App Builder.
While you can customize the User Record Page, you do that as a record page type (D), not a special “User Page” type.

B. Dashboard Page:
Dashboards are created and customized in Reports & Dashboards, not in Lightning App Builder.
You can, however, embed a dashboard component into an App Page or Record Page, but you don’t build dashboards in the App Builder itself.

Summary:
To create customized experiences for the Salesforce Mobile App, administrators use the Lightning App Builder to design App Pages (custom workspaces or homepages) and Record Pages (custom record views).
These allow tailoring layouts, components, and visibility for different users, profiles, or devices, ensuring a mobile-optimized experience.

Reference:
Salesforce Help: Lightning App Builder Overview
Trailhead: Build Custom Pages with Lightning App Builder

Explanation:

Case Assignment Rules are specifically designed to automatically route new cases to the appropriate user or queue based on predefined criteria. The administrator can set up two rule entries within a single assignment rule to meet this requirement:

Rule Entry 1: Criteria: Account: SLA Level (assuming a custom field exists) equals "Platinum Level". Action: Assign to "Priority Support Queue".
Rule Entry 2: Criteria: Account: SLA Level equals "Silver Level" or "Gold Level". Action: Assign to "Regular Support Queue".
The assignment rule evaluates these criteria upon the creation of the case and routes the record accordingly.

Why other options are incorrect
B. Case Rules: "Case Rules" is not a specific, standard feature name in Salesforce; it's a generic term. The specific feature is "Assignment Rules".

C. Workflow Rules: Traditional workflow rules are limited to updating fields on the same record or sending emails/tasks. They cannot automatically change record ownership (assignment to a queue) on a newly created record based on criteria; that is the function of assignment rules.

D. Escalation Rules: Escalation rules handle time-sensitive reassignments of existing cases that have breached an SLA time limit (e.g., still open after 4 hours). They are not used for the initial routing of new cases.

Explanation:

The requirement is to show different page layouts (and by extension, different fields and potentially picklist values) to different groups of users for the same object (Account). This is the core function of Record Types.

Let's break down each option:

D. Create one record type for customer accounts and one record type for partner accounts.
Correct. This is the standard and correct solution.
The administrator should create two record types: "Customer Account" and "Partner Account."
The "Customer Account" page layout is assigned to the "Customer Account" record type.
The "Partner Account" page layout is assigned to the "Partner Account" record type.
The "Customer Account" record type is assigned to the Sales and Support user profiles.
The "Partner Account" record type is assigned to the Partner Management user profiles.

Result: When a Sales user creates or views an Account, they see the customer layout. When a Partner Manager does, they see the partner layout.

A. Use a public group and a criteria-based sharing rule to share customer accounts with the partner team.
Incorrect. Sharing rules control record-level access (i.e., which specific accounts a user can see). They do not control the page layout a user sees for a record. A sharing rule cannot change the page layout.

B. Add members of the partner management team to the default Account team for the customer accounts.
Incorrect. Account Teams are used for sharing record access and collaboration on a specific account. They do not control the page layout. Adding a user to an Account Team grants them access to the record but does not change the UI they see.

C. Grant create, read, edit and delete access to customer accounts on the partner team profile.
Incorrect. Object permissions on a profile control whether a user can access records of an object at all. They do not control how that object is presented (the page layout). Granting access would let the partner team see customer accounts, but they would still see the customer page layout, not their specialized partner layout.

Summary:
The primary tool for controlling which page layout a user sees is the Record Type. By assigning different record types to different profiles, you can ensure each user group gets the appropriate user experience.

Reference:
Salesforce Help: "Record Types"
This documentation explains that record types allow you to offer different business processes, picklist values, and page layouts to different users, which is the foundational concept for this solution.

Explanation:

C. Global picklist (✅ Correct)

A Global Picklist (also called a Global Value Set) allows administrators to create one master list of picklist values that can be reused across multiple objects and fields.

In this case, Dream House Realty wants consistent values in the Category field on both Accounts and Cases — meaning both objects should use the same set of allowed options.

By creating a Global Value Set for the Category field:

You define the picklist values only once.
You can reuse them on multiple objects (like Accounts and Cases).
Any changes to the global value set automatically apply everywhere it’s used.
This ensures data consistency and easier maintenance.

Additionally, since the question mentions “values respective to record types,” you can restrict which picklist values appear for each record type, even when using a global value set.

D. Custom picklist (✅ Correct)

While the Global Value Set provides consistency, you still need to create a custom picklist field on each object (Account and Case) that uses that global value set.

So, the implementation involves:

Creating a Global Value Set for Category.
Creating a Custom Picklist Field on the Account object and linking it to the global value set.
Creating a Custom Picklist Field on the Case object and linking it to the same global value set.

This combination ensures consistent picklist values across objects.

❌ Incorrect Options:

A. Multi-select picklist
A multi-select picklist allows users to select more than one value, but it does not help with consistency across objects or record type restrictions. It’s also harder to use in reports and automation — not ideal for standardization.

B. Dependent picklist
A dependent picklist shows values based on a controlling field (for example, if “Country” = USA, then “State” shows only U.S. states).
While useful, it doesn’t ensure cross-object consistency and isn’t related to sharing the same value set across objects.

Summary:
To ensure that the Category field has consistent values across Accounts and Cases, Dream House Realty should use a Global Value Set (global picklist) and apply it to custom picklist fields on both objects. This allows for easy maintenance, uniform data entry, and flexibility to show specific values by record type.

Reference:
Salesforce Help: Global Value Sets
Trailhead: Customize Fields with Picklists

Explanation:

✅ Correct Answer Detail

D. Case escalation rule
Functionality: Case escalation rules are specifically designed to automatically re-route cases when they have not been closed within a specified time frame, based on criteria like the time elapsed since creation or last modification (e.g., the 24-hour SLA).
Action: A key action available within an escalation rule is to reassign the case to a different user or queue. This directly fulfills the requirement of moving the case to the "next tier queue" after the SLA is breached. They also allow for optional notification emails.
Time-Based: The core function of this rule is its time-based evaluation, which aligns perfectly with managing Service Level Agreements (SLAs).

❌ Incorrect Answers Detail
A. Einstein Case Routing
This is used for initial assignment of a case upon creation, using AI to predict the correct queue or agent. It does not handle re-assignment based on a time-based SLA breach.

B. Auto-response rule
This rule automatically sends an email reply to the customer when a new case is created. It has nothing to do with internal case re-assignment or time-based escalation.

C. Case assignment rule
This rule is used for the initial assignment of a case when it is created or updated (based on configuration). It is rule-based, not time-based, and cannot automatically trigger a re-assignment after a set period of time (like 24 hours) has passed without a change to the case.

Reference:
Salesforce Help: Set Up Escalation Rules (This documentation outlines how Escalation Rules are used to automatically reassign cases and send notifications when they aren't resolved within a specified time, which is the definition of a time-based SLA breach.)

Salesforce Help: Case Management Best Practice Guide (This resource explains the distinct purposes of different automation tools like Assignment Rules and Escalation Rules, noting that Escalation Rules are used to "Protect your service-level agreements (SLAs) by creating escalation rules that trigger follow-up actions when cases aren't resolved within defined timeframes.")