Only one theme can be active at a time, and a theme applies to the entire org.

Chatter external users see the built-in Lightning theme only.

Explanation:

When branding Salesforce with Themes in Lightning Experience, it's crucial to understand their scope and limitations to set the correct expectations. Themes are a powerful tool for applying a custom color scheme and logo, but they are not as flexible as full-page layouts.

A. Only one theme can be active at a time, and a theme applies to the entire org.
This is a fundamental characteristic of Lightning Themes. An administrator can create and customize multiple themes, but only a single theme can be activated for the entire organization. When you set an active theme, it is visible to all internal users who are on Lightning Experience. You cannot, for example, have one theme for the Sales team and a different theme for the Service team.

D. Chatter external users see the built-in Lightning theme only.
Chatter External Users (also known as Customer Community Plus users or High-Volume Community users from a sharing perspective) have a limited view of Salesforce. A key limitation is that they cannot see custom themes. They will always see the standard, out-of-the-box Salesforce Lightning theme, regardless of what theme the administrator has activated for internal users. This is a critical consideration if your branding strategy includes external collaborators.

Incorrect Answers:

B. Themes apply to salesforce classic and to the salesforce mobile app.
This statement is false.
Salesforce Classic: Themes are a feature exclusive to Lightning Experience. They have no effect on the user interface in Salesforce Classic.
Salesforce Mobile App: The Salesforce mobile app has its own distinct UI and does not inherit the branding from a custom Lightning Theme. Branding for the mobile app is configured separately, if at all.
C. Upto 150 custom themes can be created, modified, or cloned from the built-in themes.
This number is incorrect and a common distractor. While an administrator can create and work with multiple themes, the limit is not 150. You can create a much smaller number of custom themes. The precise limit can change, but it is in the range of a handful (e.g., 5-10), not hundreds. The key point is that you are limited to only activating one of them at a time.

References:
Salesforce Help - Brand Your Org with Themes - This document outlines the capabilities and limitations of Lightning Themes.
Salesforce Help - User Types - Provides context on different user types, like Chatter external users, and their capabilities.

Explanation:

Why this is correct:
Salesforce won’t let you change a custom field’s data type if that field is referenced by other metadata, and formula fields are one of the explicit blockers. If a formula anywhere (on the same object or a related one) uses that picklist, Salesforce will prevent the type change until you remove or update the formula reference.

Why the others are not correct (in this context):
B. Record types:
Record types can restrict which values of a picklist are available, but their usage doesn’t by itself block converting the field type. You may need to clean up picklist assignments after a conversion, but record type usage isn’t one of the hard “reference” blockers listed by Salesforce.
C. Visualforce:
A Visualforce page referencing the field may break functionally after a change, but Visualforce references aren’t listed as a system-level blocker to changing field type (unlike formulas/flows/Apex).
D. JavaScript:
Client-side JavaScript isn’t a Salesforce metadata dependency and won’t prevent the change (though your scripts might need updates afterward).

References
Salesforce Help: Considerations for Converting the Field Type of a Custom Field (lists what references block data-type changes, including formulas).
Salesforce Help: Error “Cannot change type due to existing data” when field is referenced by a Formula field.

Explanation:

The business requirement is to provide a "self-serve option" for customers to generate cases. This means creating channels where customers can initiate a case without directly interacting with a DreamHouse Realty employee.

Why A is Correct (Web-to-Case):
Web-to-Case allows a company to embed a case submission form directly on its public website or a customer portal. A customer can visit the webpage, fill out the form (e.g., with their contact info, warranty details, and description of the problem), and submit it. This action automatically creates a new case in Salesforce. This is a classic and powerful self-service solution.

Why D is Correct (Email-to-Case):
Email-to-Case allows customers to generate a new case simply by sending an email to a designated email address (e.g., warranty@dreamhousereality.com). The content of the email is automatically converted into a new case record in Salesforce. This is another very common and convenient self-service channel that leverages a tool (email) that customers already use regularly.

Why B is Incorrect (Case Escalation):
Case Escalation is an internal process automation tool. It is used to automatically reassign a case or send notifications if a case is not closed within a specified time frame or meets certain criteria. It is a mechanism for handling existing cases, not for allowing customers to create them.

Why C is Incorrect (Case Queues):
Case Queues are a way to group and assign cases to teams of agents, rather than to a single user. They help in managing the workload of existing cases that have been created. Like Case Escalation, this is an internal routing and management tool, not a customer-facing self-service channel for case creation.

Reference:
Salesforce Help articles on "Set Up Web-to-Case" and "Set Up Email-to-Case" describe these as the primary methods for creating cases from external sources, enabling customer self-service.

Explanation:

Case Escalation Rules are designed specifically to re-route cases and/or send notifications if they are not resolved or updated within a specified time frame (age over a certain number of hours/minutes) based on defined criteria and business hours.

B. Case Escalation Rule:
This feature allows an administrator to define criteria (e.g., case status equals 'New', case has no response from an agent) and an "age over" time threshold (2 hours in this case) after which the case can be automatically reassigned (e.g., to a manager's queue or directly to the manager) and an email notification sent to the manager.

A. Assignment Rule:
Assignment rules are used when a case is first created to automatically route it to the correct user or queue based on its initial criteria. They do not monitor cases over a period of time after creation.

C. Omni-Channel Supervisor:
This is a real-time monitoring tool for supervisors to view agent workloads, queue backlogs, and work items. It helps supervisors manually intervene, but it does not automatically trigger actions or notifications based on predefined time limits.

D. Formula Field: A formula field performs calculations or displays data based on other fields. It cannot initiate time-based actions like sending notifications or reassigning records.

Explanation:

Why:
In Flow, a checkbox field evaluates to a Boolean. To branch when High_Value_Customer__c = TRUE, configure the Decision outcome with:
Resource: {!High_Value_Customer__c}
Operator: Equals
Value: {!$GlobalConstant.True}
If true, route to the second screen (skip the first).

Why the others are wrong:

B. “Use the equals operator and “High Value Customer” as the value.”
Type mismatch: A checkbox stores True/False, not text. Comparing a Boolean resource to a Text literal like "High Value Customer" is invalid.
Wrong operand meaning: "High Value Customer" is the field label, not a value the field ever contains. A checkbox doesn’t hold the words “High Value Customer”—it’s either checked (True) or unchecked (False).

C. “Use the contains operator and {!$GlobalConstant.False} as the value.”
Operator not applicable: Contains is for Text or Collections (e.g., “Does this string include that substring?” or “Does this collection include that item?”). It doesn’t apply to Boolean fields.
Wrong logic anyway: The requirement is “skip the first screen when the checkbox is True.” Checking for False would do the opposite—even if the operator were valid (it isn’t).

D. “Use the contains operator and “High Value Customer” as the value.”
Operator not applicable (again): Contains doesn’t work with Boolean fields—only text or collections.
Meaningless comparison: You’d be looking for the string "High Value Customer" inside something. A checkbox doesn’t contain text; it’s just True/False. Also, using the field’s label string in a decision is never how you evaluate a checkbox’s value.

Explanation:

C. Default Language:
This setting, found in the Company Information page, determines the default language for the organization. For a global team, setting a clear default is essential. While individual users can set their personal language preference, the org-wide default acts as the fallback for all new users, system messages, and certain text fields that are not translated by the individual user setting.

D. Currency Local:
For a global company operating in multiple regions, the Currency Local (also known as Default Locale or Organization Locale) is critical. It determines the format for:

Date and Time (e.g., DD/MM/YYYY vs. MM/DD/YYYY).
Number formatting (e.g., comma as a decimal separator vs. period).

Currency display symbols. This ensures that data is displayed in a consistent, regionally appropriate format for all global users, which is essential for minimizing confusion and data entry errors.

❌ Incorrect Answers and Why They Are Wrong

A. Login Hours:
This setting is configured at the Profile level, not in the Company Information settings. It is used to restrict when a specific group of users can log in, which is a security control, not a fundamental global configuration for language or locale.

B. Password Policy:
This setting is configured under Security Controls (or Identity in Lightning), not in the Company Information settings. It defines rules like password length, history, and expiration for all users in the org, which is a global security setting, but not one of the primary localization or company detail settings requested.

Reference
Salesforce Help Documentation: Manage Information About Your Company
This resource confirms that settings for Default Language and Default Locale (which affects currency display, date, and time formats) are configured under Company Information and are essential for global user support.

Explanation:

Permission Sets allow an administrator to grant additional permissions to specific users without changing their profile. In this scenario:
All marketing users share one profile (with read-only access to Campaigns).
A few users need edit access.
➡️ The best solution is to create a Permission Set with “Edit” (or “Modify All”) access on the Campaign object and assign it only to those specific users.
This approach follows the Salesforce principle of least privilege + flexibility, avoiding the need to clone or manage multiple profiles.

❌ Why the others are wrong

B. Organization-Wide Defaults (OWD):
OWDs control the baseline level of record access (Private, Public Read Only, etc.), not object-level permissions like Create/Edit/Delete. Even if OWDs are “Public Read Only,” a user still needs object-level “Edit” permission to modify a record.

C. Marketing User checkbox:
This special checkbox (on the user record) enables Campaign management features like campaign creation or import, but it doesn’t override the profile’s object permissions. Users still need “Edit” rights on Campaigns to make changes.

D. Field-Level Security:
Controls visibility or editability of individual fields, not object-level access (like whether the user can create or edit Campaign records at all).

Reference:
Salesforce Help: Permission Set Overview
Trailhead: Control Access to Objects and Fields with Permission Sets

Explanation:

The question is about standard Salesforce objects that are available "out of the box" (meaning, without any custom development) and are relevant to a support use case.

Why B is Correct (Case):
The Case object is the central, core standard object for any customer service or support operation in Salesforce. It is specifically designed to track customer issues, questions, and requests. Any evaluation of Salesforce for a service team would start with the Case object.

Why E is Correct (Account):
The Account object is the standard object representing a business account or company. In a support context, it is crucial to know which customer is submitting a Case. Cases are typically related to an Account to provide that business context.

Why A is Correct (Contract):
The Contract object is a standard Salesforce object used to define support terms, service level agreements (SLAs), and entitlements. In a support use case, contracts can be used to determine what level of support a customer is entitled to, which is a fundamental part of a professional service operation.

Why C is Incorrect (Ticket):
While "ticket" is a common industry term for a support request, it is not the name of a standard Salesforce object. The equivalent standard object is Case. "Ticket" could be the name of a custom object, but the question asks for standard objects available out of the box.

Why D is Incorrect (Request):
"Request" is not a standard Salesforce object. Like "Ticket," this is a generic term, but the specific standard object built for handling service requests is the Case object.

Reference:
These are core standard objects in the Salesforce schema. The Service Cloud implementation guide consistently centers on the Account, Contact, Case, and Contract/Entitlement objects as the foundation for managing customer service.

Explanation:

✅ Why this is correct
A Validation Rule is the right way to enforce data requirements based on conditions across multiple fields.
You can create a rule on the Opportunity object such as:

AND(
ISPICKVAL(StageName, "Closed Won"),
ISBLANK(TEXT(LeadSource))
)

Error Message:
“Lead Source must be selected before setting Stage to Closed Won.”
This ensures users cannot save an Opportunity with Stage = Closed Won unless Lead Source is populated.

❌ Why the others are wrong

A. Make Lead Source a dependent picklist to the Opportunity Stage field
You can’t make Lead Source dependent on Stage because both are picklists that don’t have a parent-child relationship defined that way. Also, dependency doesn’t enforce completeness—it just filters available values.

C. Change the Opportunity Stage field to read-only on the page layout
Making the field read-only would prevent all users from changing the stage—not conditional enforcement based on Lead Source.

D. Modify the Opportunity Stage as a dependent picklist to the Lead Source field
While you can create picklist dependencies, StageName is a standard, special field tied to the Opportunity pipeline process and cannot be made dependent on another field like Lead Source.

Reference:
Salesforce Help: Create Validation Rules
Trailhead: Ensure Data Quality with Validation Rules

Explanation:

The requirement is to distribute credit for a single Opportunity among multiple team members, with the distribution based on each person's specific level of effort. This is the exact purpose of Opportunity Splits.

Why B is Correct (Splits): Opportunity Splits is a standard Salesforce feature that allows you to divide the credit (i.e., the revenue) from a single Opportunity among multiple team members or business units. The administrator can create a custom "Split Type" called "Level of Effort" and then team members can be assigned a specific percentage of the Opportunity amount. When the Opportunity is closed and won, these splits are used for accurate forecasting and reporting on individual performance.

Why A is Incorrect (Stages): Stages represent the phases of a sales process (e.g., Prospecting, Negotiation, Closed Won). They track the progress of the entire Opportunity, not how credit is distributed among the team members working on it.

Why C is Incorrect (Queues): Queues are holding bins for work items (like Leads or Cases) that need to be assigned to a user. They are used for managing workload distribution, not for allocating monetary credit or revenue sharing on a specific record.

Why D is Incorrect (List Views): List Views are ways to display and filter lists of records. They are a reporting and data visibility tool and have no functionality for assigning or calculating credit percentages.

Reference:
Salesforce Help article "About Opportunity Splits" explains that splits "let your sales reps share credit for an opportunity... You can use splits to divide an opportunity’s amount among... team members, and track split amounts in forecasts."

Explanation:

Why It’s Correct:
Salesforce Knowledge Articles are the ideal solution for delivering structured, reusable content such as troubleshooting tips, FAQs, and how-to guides. These articles can be surfaced in case responses, email templates, and self-service portals, allowing support agents to quickly provide relevant information to customers. In this scenario, the support manager wants to include the top five troubleshooting tips in responses — a perfect use case for Knowledge Articles, which can be curated and updated centrally for consistency and speed. This feature is part of Salesforce Knowledge, which empowers service teams to share expertise efficiently.

❌ Incorrect Answers and Why They’re Wrong

A. Auto-Response Rules
Auto-response rules are used to send automated emails when a case is created, but they do not generate or manage content like troubleshooting tips. While they can include links to Knowledge Articles, they are not the source of the content.

B. Email Alerts
Email alerts are part of workflow automation and are used to notify users or customers based on specific triggers. However, they do not provide dynamic or curated content like troubleshooting tips unless paired with templates or articles.

D. Assignment Rules
Assignment rules route cases to the appropriate user or queue based on criteria. They are focused on internal case management, not customer communication or content delivery.

References
Salesforce Help: Knowledge Articles Overview
Trailhead: Service Cloud Knowledge

Explanation:

When using Data Loader to connect to Salesforce via the API, the tool requires a valid username, password, and—for security reasons outside of trusted IP ranges—the user’s security token appended directly to the end of the password (with no spaces). This token is a unique, auto-generated code sent via email when a user resets their password or can be manually reset in personal settings. This step authenticates API access securely and is mandatory for external tools like Data Loader unless the user’s IP is whitelisted in Network Access or they’re using OAuth (not default in Data Loader’s standard login).

Why the Incorrect Answers Do Not Work

Option A is incorrect because there is no specific permission set required just to "import data"—the "API Enabled" permission is controlled at the profile level (or via permission sets), and it’s enabled by default in most standard profiles (e.g., System Administrator). Simply adding a permission set is not a required step.

Option C is wrong because the Data Import Tool (or Data Import Wizard) is a browser-based, limited tool for importing Accounts, Contacts, Leads, Solutions, and Campaign Members—it does not support custom objects and is not the same as Data Loader.

Option D is unnecessary and misleading; while resetting a password does generate a new security token, it’s not required every time—users can log in with their existing token as long as it’s valid, and resetting both is overkill and not a standard prerequisite.

References:
Salesforce Help: Log In to Data Loader
Salesforce Help: Reset Your Security Token
Trailhead: Prepare for Data Loader