Explanation:

The two correct answers are C and D.

C. An object can have 25 roll-up summaries.
This is a key Salesforce platform limit. An object, such as the Account object in this scenario, can have a maximum of 25 roll-up summary fields. The proposal mentions summarizing 15 fields from three separate objects. While the total number of fields to summarize (15 x 3 = 45) might seem to exceed this limit, the question is about summarizing "15 fields... on the Account object" from each of the three objects. The more critical point is that even if the sales reps only need a few key metrics, the total number of roll-up summary fields on the parent object (Account) cannot exceed 25. This is a hard limit and a critical consideration for the proposal.

D. Roll-up summaries are limited to master-detail relationships.
This is a fundamental rule of Salesforce. A roll-up summary field can only be created on the master object in a master-detail relationship. In the proposal, one of the three custom objects has a master-detail relationship with the Account. This means you can create roll-up summary fields for that single object. However, the other two objects have relationships that are not master-detail (likely lookups), which means you cannot create roll-up summary fields for them directly. This is a significant consideration that invalidates a large part of the proposal's original design, as it stands. To achieve the summary for the other two objects, alternative solutions would be needed, such as Apex triggers, flows, or third-party apps.

Why the Other Options Are Incorrect?

A. Roll-up summaries allow MAX, MIN, SUM, COUNT, and AVG.
This option is incorrect because roll-up summaries do not support the AVG (average) function out-of-the-box. The supported functions are COUNT, SUM, MIN, and MAX. While you can achieve an average by creating two roll-up summary fields (one for SUM and one for COUNT) and then a formula field to divide them, AVG is not a direct, single function available for roll-up summary fields.

B. An object can have 20 object references.
This statement is not a standard Salesforce platform limit in the context of this question. The number of roll-up summary fields is limited to 25. The number of relationships (lookups, master-detail) a single object can be on the detail side of is a different topic and generally not a primary consideration for the number of roll-up summaries you can create. There are various limits related to relationships and fields on an object, but "20 object references" is not an accurate, standard limit relevant to this scenario.

References:
Salesforce Help Documentation: "Roll-Up Summary Field Overview" - This documentation clearly states that roll-up summary fields are available only for master-detail relationships and lists the supported functions (SUM, COUNT, MIN, MAX).
Salesforce Limits: You can find the specific limits for various Salesforce features by searching for "Salesforce Limits" or "Roll-Up Summary Field Limits." This will confirm the limit of 25 roll-up summary fields per object.

Explanation:

Correct Answer: C. Feed tracking ✅

Why this is correct:
Feed Tracking lets you automatically create Chatter posts on a record’s feed when specific fields are updated.
In this case, when a Travel Request’s “Status” field = Approved, Salesforce can post that update to the record feed so everyone following it is notified.
This matches exactly what the Rangers want: automatic posts on the record when a request is approved.

Why not the others:

A. Auto-response rule ❌
Used in Case Management or Web-to-Lead/Case to automatically send email replies.
Has nothing to do with posting updates to a record feed.

B. Workflow rule ❌
Workflow rules can update fields, send emails, or create tasks.
They cannot directly post to Chatter feeds.
(Note: you’d use Process Builder/Flow with a Post to Chatter action, but the simpler/best answer here is Feed Tracking.)

D. Feed quick action ❌
A quick action is something a user clicks manually (e.g., “Post to Feed” button).
That would not be automatic — it requires user input.

📖 Reference:
Salesforce Help: Customize Chatter Feed Tracking
Trailhead: Chatter for Collaboration module

Explanation:

Correct Answer: D. Path
Salesforce Path is a feature designed to guide users through specific stages of a process, like a sales process. It displays key fields, guidance, and tips for each stage, making it perfect for helping new sales reps understand what to do at each step. For example, in the Opportunity object, Path can show stages like “Prospecting” or “Closed Won” and provide tailored help text, such as “Enter the customer’s budget here” or “Follow these tips to close the deal.” This makes it an ideal tool for a help guide that supports reps during sales processes, meeting the manager’s need for an easy-to-use solution.
Path is simple to set up in Salesforce, and an App Builder can configure it to align with the sales process, ensuring reps get the right guidance at the right time.

Why the Other Options Are Incorrect?

A. Flow:
Flows in Salesforce are used to automate processes or guide users through a series of screens to collect or update data. For example, a Flow might walk a rep through entering customer details step by step. While Flows are powerful for automation or data entry, they’re not designed specifically for providing ongoing guidance or help during a process like Path is. They’re more complex to set up for this purpose and not the best fit for a simple help guide.

B. Journey Builder:
Journey Builder is part of Salesforce Marketing Cloud, used to create automated customer journeys, like sending emails or SMS based on customer behavior. For instance, it might send a follow-up email after a purchase. It’s focused on marketing automation, not on guiding sales reps through their daily sales processes. This makes it irrelevant for the manager’s need for a help guide.

C. Chatter Publisher:
Chatter is Salesforce’s collaboration tool, allowing users to post updates, share files, or ask questions in a social-media-like feed. For example, a rep could post a question in Chatter to get help from colleagues. While Chatter supports team communication, it’s not a structured help guide for sales processes. It’s more about ad-hoc collaboration, not providing stage-specific guidance like Path.

Summary:
Path (Option D) is the best choice because it directly addresses the need for a help guide by providing stage-specific tips and fields for sales reps. Flow is better for automation, Journey Builder is for marketing, and Chatter is for collaboration—none of these meet the requirement as effectively as Path.

Reference:
Salesforce Help: Set Up a Path
This documentation explains how to configure Path for objects like Opportunities, including adding guidance for success.

Explanation:

The use of External ID fields is a fundamental concept in data management and integration within Salesforce. They are crucial for ensuring data integrity when synchronizing records between Salesforce and external systems. Let's break down the technical details behind each option.

Why A is Correct: The Number data type is one of the primary field types designed to hold unique identifiers from external systems, especially if those systems use numeric keys (e.g., 1001, 1002). When marked as an External ID, a Number field can be used to upsert records via the API, allowing the external system's numeric ID to be the key for matching and preventing duplicates.

Why D is Correct: The Text data type is the most common and versatile type for an External ID. Alphanumeric identifiers (e.g., "PROP-257a", "EXT-987YZ") are extremely common in external systems. A Text field designated as an External ID provides a flexible and powerful way to match on these complex keys during data import and integration processes.

Why B is Incorrect: The URL data type is specifically formatted to store web addresses (e.g., https://www.example.com). While a URL might be unique, it is not a suitable data type for a unique record identifier used for matching and upserting. Salesforce does not allow you to assign the "External ID" attribute to a field of type URL. Its purpose is for display and linking, not for use as a key in data operations.

Why C is Incorrect: The Phone data type is designed to store telephone numbers. While phone numbers can be unique, they are poor candidates for a stable, unique key for several reasons: formatting can vary ((555) 123-4567 vs. 5551234567), numbers can be reassigned, and individuals may have multiple numbers. More importantly, from a technical standpoint, Salesforce does not allow you to check the "External ID" checkbox on a field with the Phone data type. This functionality is restricted to other field types.

Key Takeaway: Not all field types can serve as an External ID. This feature is reserved for specific field types that are appropriate for storing stable, unique identifiers. The most common and intended types for this purpose are Text, Number, and Email fields. Always check the field's type properties in Setup to see if the "External ID" attribute is available.

Reference:
Salesforce Help: Field Types (See which types can be set as an External ID)
Salesforce Help: Upserting Records (Explains how External IDs are used for data operations)

Explanation:

The two correct answers are A and B.

A. Create an approval process on the Contract object with criteria set on a second approval step set as 'Amount__c > 10,000' and set the approver as director.
This option directly addresses the requirement for tiered approvals. An approval process allows you to define different approval steps with specific criteria. The first step would route to the sales manager, and the second step, with the criteria Amount__c > 10,000, would automatically route the record to the director. This is the standard, declarative way to build a multi-step approval workflow in Salesforce.

B. Create an approval process on the Contract object and set the field for 'Next Automated Approver Determined By' as 'Manager'.
This option is the declarative solution for sending the initial approval request to the sales manager. The "Next Automated Approver Determined By" field within an approval process allows you to automatically assign the approver based on a user's standard or custom hierarchy field. In this case, setting it to 'Manager' will automatically look up the submitting user's manager and assign them as the first approver, fulfilling the first part of the approval requirement.

Why the Other Options are Incorrect?

C. Create a validation rule on the Contract object that prevents updates to the contract record while it is being reviewed.
While a validation rule can prevent updates, it is not the correct tool for this task within an approval process context. The built-in functionality of a Salesforce approval process already handles this. Once a record enters an approval process, it is automatically locked from edits by anyone except for an administrator or the designated approver. This is a core feature of the approval process designed specifically to prevent changes while a record is under review. Creating a separate validation rule is redundant and unnecessary.

D. Create an approval process on the Contract object with one step for each sales manager that sets the approver as the director.
This is an inefficient and impractical solution. It suggests creating a separate approval step for every single sales manager in the company, which is not a scalable or maintainable approach. The goal is to route to the submitting user's manager, not to a specific sales manager. This would require constant updates to the approval process as new managers are hired or roles change. Options A and B provide a much more dynamic and scalable solution by using user-hierarchy fields and criteria-based steps.

References:
Salesforce Help Documentation: "Approval Processes" - This is the primary resource for understanding how to set up approval steps, entry criteria, and automated approvers.
Salesforce Trailhead: "Automate Simple Business Processes with Approvals" - This module provides hands-on practice and a deeper understanding of how approval processes work, including how to lock records and set up multi-step workflows.

Explanation:

Correct Answer: A. Import Wizard ✅

Why this is correct:
The Data Import Wizard is designed for smaller data volumes (up to 50,000 records), which fits Cloud Kicks’ need to load 25,000 records.
Import Wizard also includes deduplication features (it can prevent duplicates when importing by matching on record ID, name, or email depending on the object).
Since the question explicitly asks for deduplication, this is the right tool.

Why not the others:

B. Lightning Object Creator ❌
Used to quickly create custom objects from spreadsheets.
Not meant for mass data import into an existing custom object like Race_Track__c.

C. Data Loader ❌
Yes, Data Loader can handle very large volumes (millions of records).
But it does not provide deduplication on its own — it just inserts or upserts based on ID.
Since deduplication is the key requirement here, Data Loader isn’t the best choice.

D. Schema Builder ❌
Schema Builder is for creating/modifying objects, fields, and relationships visually.
It has nothing to do with importing records.

📖 Reference:
Salesforce Help: Data Import Wizard
Salesforce Help: Data Loader

Explanation:

Correct Answer: D. Checkbox

Why Checkbox is Correct?
A Checkbox field is the best choice because it allows users to indicate a simple yes/no or true/false condition—in this case, whether a contract was sent for an Opportunity. For example, a sales rep can check a box labeled “Contract Sent” to confirm the contract was sent before marking the Opportunity as “Closed Won.” This field type is straightforward and perfect for tracking a binary status (sent or not sent).
For reporting, a Checkbox field makes it easy to count Opportunities with the box checked (contract sent) versus unchecked (contract missing). For instance, a report can show “50 Opportunities with Contract Sent = True” and “20 with Contract Sent = False.” An App Builder can also use validation rules to ensure the “Contract Sent” checkbox is checked before allowing the Opportunity to be marked “Closed Won,” meeting UC’s requirement.

Why the Other Options Are Incorrect?

A. Text: A Text field allows users to enter free-form text, like “Contract sent on 8/25/2025.” While this could store information about the contract, it’s not ideal for reporting because the data isn’t standardized. For example, one rep might write “Sent,” another “Yes,” or “Contract mailed,” making it hard to compare and report consistently. A Checkbox is simpler and ensures uniform data for reporting.

B. Text Area: A Text Area field is for longer text entries, like notes or descriptions (e.g., “Details about the contract sent to the client”). Like the Text field, it’s not standardized, so reporting on whether a contract was sent would be difficult. For example, sorting through varied notes to determine “sent” versus “not sent” is inefficient compared to a Checkbox’s clear true/false value.

C. Picklist: A Picklist field offers a dropdown menu with predefined options, like “Sent,” “Not Sent,” or “Pending.” While a Picklist could work, it’s more complex than needed for a simple yes/no requirement. For example, a Picklist with just “Yes” and “No” duplicates the functionality of a Checkbox but requires more clicks to configure and use. A Checkbox is the simpler, more direct choice for this binary scenario.

Summary:
The Checkbox field (Option D) is the best fit because it provides a simple, standardized way to track whether a contract was sent (true/false) and supports easy reporting on Opportunities with sent versus missing contracts. Text and Text Area fields lack standardization, making reporting harder, and a Picklist is unnecessarily complex for a yes/no question.

Reference:
Salesforce Help: Custom Field Types
This documentation describes field types, including Checkbox, and their use cases, such as tracking binary conditions.

Explanation:

The "Allow Customer Invitations" setting is a powerful feature that bridges the gap between an organization and its external customers, transforming Salesforce from an internal system of record into a collaborative platform. Let's dissect what this enables and why the other options do not apply.

Why D is Correct:
When a Customer (typically a Contact from an associated Account) is invited to a Chatter group, they are granted a very specific, limited set of permissions. Their primary capability is to interact within the confines of that specific group. This interaction includes:

→ Viewing group posts and files.
→ Creating their own posts.
→ Commenting on posts.
→ Liking posts.
→ @mentioning other members who are already in the same group.

This permission is fundamentally about enabling bi-directional communication and collaboration within a controlled environment.

Why A is Incorrect:
The ability to manage group membership is an administrative function. External users invited as Customers have a "Read/Write" access level to the group itself, but this does not include the privilege to manage the group's membership. Inviting new members, even to groups they are in, is a permission reserved for internal users with the "Invite Customers to Chatter" permission or group owners/managers.

Why B is Incorrect:
This option is partially misleading. An invited Customer user can use the @mention feature, but its scope is severely restricted. They can only @mention:

1. Other members within the same Chatter group they have been invited to.
2. Themselves.

They cannot @mention just any user at the company, nor can they @mention an Account record. @mentioning an Account would notify all users following that Account, which is an internal collaboration feature not extended to external customers.

Why C is Incorrect:
The ability to request access is not a function tied to this specific setting. Furthermore, public groups are, by definition, open. Any user who can see Chatter can see and join a public group without needing to request access. This option describes a scenario that doesn't exist; you join public groups, you request access to private groups. However, the "Allow Customer Invitations" setting is about granting access via direct invitation, not about a customer's ability to seek out and request access to other groups.

Key Takeaway:
Enabling "Allow Customer Invitations" extends Chatter's collaborative power to external customers in a secure and controlled manner. It is not about giving them administrative rights or full access to the org's social network. Their world becomes the group(s) to which they have been explicitly invited.

Reference:
Salesforce Help: Allow Customer Invitations
Salesforce Help: Chatter Customer Group Membership (Details the precise permissions of customer users in groups)

Explanation:

To control which fields a user can see on an object, you use field-level security (FLS). This is the most granular level of control for data visibility in Salesforce. It determines whether a user can view, edit, or delete the value of a specific field. FLS is configured on the profile or permission set and applies across the entire platform, including page layouts, reports, and API access.
In this scenario, the requirement is to show the "Jupiter" field only to users with the "Outer Planets" profile. By setting the field-level security for the "Jupiter" field to "Visible" only on the "Outer Planets" profile, you ensure that no other profile can see the field, regardless of the page layout.

Why the Other Options are Incorrect?

A. Classic encryption:
This is a security feature used to encrypt data at rest, making it unreadable in the database. It's not a tool for controlling field visibility based on a user's profile. Classic encryption is meant to protect sensitive data from being accessed by unauthorized parties, but it doesn't solve the problem of making a field visible to one profile and invisible to all others.

B. Filtered view:
A filtered view, or a list view, is a tool for filtering a list of records based on criteria. It affects which records are displayed in a list, not which fields are visible on a record's detail page. It's a tool for record-level filtering, not field-level visibility.

D. Sharing rules:
Sharing rules are used to grant additional record-level access to users or groups, beyond what's defined by the organization-wide defaults (OWD). They control which records a user can see, not which fields they can see on those records. For instance, a sharing rule might give a user access to all "Solar System" records owned by a specific sales team, but it won't hide a field like "Jupiter" from that user if they already have field-level access to it. Sharing rules and field-level security operate at different levels of the Salesforce security model.

References:
Salesforce Help: Field-Level Security
Salesforce Trailhead: Data Security

Explanation:

The business requirement:
→ Once Job Accepted is marked (candidate accepted the offer)…
→ The Hire Date must be entered (so not blank).
→ After it’s entered, it cannot be changed on later edits.
So we want a validation rule that fires when someone tries to change the Hire Date after the job has been accepted.

✅ Correct Answer: A. NOT(ISBLANK(Job_Accepted__c)) && ISCHANGED(Hire_Date__c)

Why this works:
→ NOT(ISBLANK(Job_Accepted__c)) → means the Job Accepted field has a value (offer was accepted).
→ ISCHANGED(Hire_Date__c) → means someone is trying to change the Hire Date.
→ Together, this rule prevents the Hire Date from being changed once the job has been accepted.
This matches the requirement exactly.

Why the others are incorrect:

❌ B. (ISBLANK(Job_Accepted__c) || NOT(ISCHANGED(Hire_Date__c)))
This is backwards: it would block edits when the job is not accepted or when the hire date is unchanged — which doesn’t make sense.

❌ C. NOT(ISBLANK(Job_Accepted__c)) || ISCHANGED(Hire_Date__c)
Notice the OR (||) instead of AND (&&).
This would block any edit once the job is accepted (even unrelated fields), and also block when the hire date is changed regardless of acceptance. Too restrictive.

❌ D. (ISBLANK(Job_Accepted__c) && NOT(ISCHANGED(Hire_Date__c)))
This would only fire if job accepted is blank and hire date isn’t changed — not relevant at all.

📖 Reference:
Salesforce Help: ISCHANGED function
Salesforce Help: Validation Rules

Explanation:

Why these are correct:

A. My Domain must be deployed
In Salesforce, you cannot use custom Lightning components (like ones from AppExchange or custom-built) in the Lightning App Builder until My Domain is enabled and deployed.
This is because Lightning Components rely on namespace isolation, which My Domain provides.
Without My Domain, the component simply won’t appear in the Lightning App Builder.

D. The component is tagged for record pages instead of home pages
When developing Lightning components, the developer sets targets in the component’s .xml configuration file (e.g., lightning__RecordPage, lightning__HomePage, lightning__AppPage).
If the component is only tagged for Record Pages but not for Home Pages, it won’t show up when you try to add it to the Home page.
This is a common real-world issue with downloaded components.

Why the others are incorrect:

B. A custom tab must be created ❌
Creating a custom tab has nothing to do with placing a component on a Home Page.
Tabs are for navigation, not for component visibility in the Lightning App Builder.

C. The component requires a developer permission ❌
There is no such thing as a special “developer permission” required just to place a component on a page.
The visibility is controlled by My Domain + component targets, not permissions like “Author Apex” or “Modify All Data.”

📖 Reference:
Salesforce Docs: Enable My Domain
Salesforce Dev Guide: Configure Lightning Component for Lightning Pages

Explanation:

Process Builder is the best tool for this scenario because it can handle complex automation tasks, including updating a field and sending an outbound message with a time delay. In this case, when a lift is sold, Process Builder can:

→ Update the “To Be Installed” checkbox field to “True” on the Lift object.
→ Schedule an action to send an outbound message to the external system the next day.

For example, if a lift is marked as sold on August 26, 2025, Process Builder can automatically check the “To Be Installed” box and schedule an outbound message to notify the external system on August 27, 2025. Process Builder supports time-based actions, which are perfect for the “next day” requirement, and it can trigger outbound messages, which are used to communicate with external systems.

Process Builder is flexible, user-friendly for App Builders, and designed to handle multi-step automation like this, making it the ideal choice.

Why the Other Options Are Incorrect?

A. Approval Process: An Approval Process is used to route records for approval, such as when a manager needs to approve a discount on a deal. For example, if a lift sale required manager approval, this would be appropriate. However, this scenario doesn’t involve approvals—it’s about automatically updating a field and sending a message. Approval Processes can’t handle field updates or time-based outbound messages, so this option doesn’t fit.

B. Workflow: Workflow Rules are a legacy automation tool in Salesforce that can perform actions like field updates or sending outbound messages when a record meets certain criteria. For example, a Workflow could check the “To Be Installed” box when a lift is sold. However, Workflow Rules don’t support time-based actions, so they can’t delay the outbound message until the next day. This limitation makes Workflow unsuitable for the full requirement.

C. Flow: Flows are powerful for creating complex automation or guided user experiences, like a screen flow to collect data or an autolaunched flow to update records. For instance, a Flow could update the checkbox and send an outbound message. However, scheduling a time-based action (like waiting until the next day) requires additional setup, such as combining Flow with a scheduled job, which is more complex than using Process Builder’s built-in time-based actions. Process Builder is simpler for this specific task.

Summary: Process Builder (Option D) is the best choice because it can update the “To Be Installed” checkbox and schedule an outbound message for the next day in a single, easy-to-configure process. Approval Process is for approvals, not automation; Workflow can’t handle time-based actions; and Flow is unnecessarily complex for this scenario.

Reference:
Salesforce Help: Automate Processes with Process Builder
This documentation explains how Process Builder can handle field updates, outbound messages, and time-based actions.