Explanation:

The requirement is to manage different pricing for different types of customers (reseller partners vs. standard customers). The native Salesforce feature designed specifically for this scenario is Price Books.

Let's break down each option:

D. Create a separate PriceBook for reseller partners.
Correct. The administrator should create a new Price Book called "Reseller Partner Price Book." In this price book, they can add the same products but with discounted list prices. When a sales rep creates an Opportunity for a reseller partner, they simply select the "Reseller Partner Price Book," and the discounted prices will automatically be applied to the products they add. This is the standard, scalable, and manageable solution.

A. Add a Partner_Discount_c field to the Opportunity
Incorrect. While a custom discount field can be used to apply a one-time discount to an entire opportunity, it is a manual and less precise process. It does not provide a structured way to manage and maintain a specific set of discounted prices for a whole catalog of products. A price book is the correct tool for managing a catalog of standard prices.

B. Build separate reseller partner products.
Incorrect. This would create massive data duplication and become a maintenance nightmare. The administrator would have to create and maintain two separate versions of every product (e.g., "Product A" and "Product A - Reseller"). This is an inefficient and error-prone approach.

C. Use a different Opportunity record type.
Incorrect. A record type controls the page layout, picklist values, and business process. It does not control the pricing of products added to the opportunity. You cannot assign a specific price book to a record type.

Summary:
Price Books are the declarative tool for managing multiple pricing strategies for the same set of products. Creating a dedicated price book for reseller partners is the most efficient and sustainable solution.

Reference:
Salesforce Help: "About Price Books"
This documentation explains that price books let you "create custom product catalogs with your own pricing for different markets and segments," which is the exact requirement for offering discounted prices to reseller partners.

Explanation:

Salesforce access control for objects (Object-Level Security) is defined by profiles and permission sets, which specify whether a user can Create, Read, Edit, or Delete (often abbreviated as CRUD permissions) records of a particular object.
The question clearly states that the analytics user must be able to Read, Create, and Edit records but not Delete any.

Why Option C is Correct:
Creating a custom profile allows the administrator to precisely define the level of object access.
By cloning an existing profile (like the Standard User or Analytics Cloud Integration User) and removing the Delete permission for all required objects, the admin can ensure the user retains the ability to:
- Read (view data),
- Create (add new records),
- Edit (update records),
but cannot Delete records under any circumstances.
This setup provides fine-grained control over CRUD permissions, ensuring compliance with data retention and integrity policies.
A custom profile is the best long-term, maintainable solution when deletion must be globally restricted.

❌ Incorrect Options:
A. Assign the standard System Administrator profile to the analytical user.
The System Administrator profile grants full CRUD access (Create, Read, Edit, Delete) on all objects, along with many administrative privileges. This would allow deletion and excessive access — not suitable for a restricted analytics user.

B. Give the user View All access and assign them to the highest role in the role hierarchy.
“View All” allows users to see all records of an object, regardless of sharing rules, but it doesn’t control editing or deleting capabilities. Also, role hierarchy affects record visibility, not CRUD permissions. This doesn’t restrict deletion — in fact, it could increase access visibility, which is not desired here.

D. Create and assign a permission set that includes Read, Create, and Edit access.
A permission set can add permissions to a user’s existing profile, but it cannot remove permissions that are already granted. If the base profile includes “Delete” access, a permission set cannot take it away. Therefore, this option doesn’t solve the problem.

Summary:
To ensure the analytics user can view, create, and edit records but cannot delete them, the administrator must create a custom profile that removes Delete permissions from the relevant objects. Permission sets can only grant additional permissions, not restrict them, and assigning a system administrator profile or adjusting roles does not limit object-level access. This makes a custom profile the most precise and secure solution.

Reference:
Salesforce Help: Profiles Overview
Trailhead: Control Access to Records → Configure Object-Level Security

Explanation

A formula field is the most efficient and accurate way to automatically calculate and display the warranty expiration date based on a different date field.
The administrator can create a custom date formula field on the Installation object.
The formula would reference the Installation Date field (or Warranty Purchased Date if a separate field exists) and automatically add 365 days (or use a function like ADDMONTHS(date_field, 12)).
This ensures consistency, prevents data entry errors, and automatically handles the calculation for both standard 1-year warranties and extended warranties (provided the input date field reflects the actual start date).

Why other options are incorrect
A. Use a formula as the default value of the warranty Expiration Date field: Formula fields calculate values dynamically and display them; they do not serve as a default value for a data entry field that a user can later edit. A default value can only be a static date or another simple formula, but the user could potentially overwrite it incorrectly.
C. Add a validation rule to ensure the Expiration Date field is populated: A validation rule ensures a field isn't blank, but it does not automate the calculation of the date itself. This would still require the installer to manually calculate and enter the correct date, which is prone to errors.
D. Include the warranty Expiration Date field on the mobile page layout: This makes the field visible to the installer on the mobile app, but it does not automate the calculation. The installer would still have to manually input the date, which is inefficient and a source of potential errors. The best approach is to automate the calculation with a formula field that is read-only on the layout.

Explanation:

Why D Is Correct
AW Computing needs to keep one Contact record (the contractor) but track their history with multiple agencies over time — exactly what Contacts to Multiple Accounts (also called “Direct Relationships” or “Account Contact Relationships”) was built for.
How it works:
- Enable the feature
Setup → Account Settings → Allow Contacts to Multiple Accounts → Check the box
- On any Contact, click Related Accounts → Add Relationship
- Select the Agency (Account)
- Set Role (e.g., “Current Contractor”, “Former Contractor”)
- Set Start Date and End Date
- Mark Active or Inactive
Result:
- One Contact record (no duplicates)
- Full historical accuracy (shows every agency they’ve worked with and when)
- Native Related Account list on the Contact
- Works in reports, list views, and Path

This is Salesforce’s official recommended solution for contractors, consultants, board members, or any person who works with multiple companies.

Why the Other Options Fail
Option A – Use a partner community to track the Contacts completely fails because a Partner Community is nothing more than an external login portal for partners or contractors. It has zero capability to store or display historical agency relationships. Even if the contractor logs in, the underlying data model remains the standard one-to-one Contact-to-Account link, so there is no native way to show that Jane Doe worked for Agency A in 2022 and Agency B in 2024 without creating duplicate Contact records. The community only controls who can see what, not how relationships are structured.
Option B – Create a new Contact record for each agency is the worst possible approach for historical accuracy. Every time the contractor switches agencies, you would duplicate the same person (same name, email, phone, LinkedIn, certifications, etc.), instantly creating data quality nightmares: duplicate emails trigger duplicate rules, activity history is split, reporting becomes impossible (“How many unique contractors did we work with?”), and you lose the true identity of the individual. This directly violates the requirement for historical accuracy because the old records become orphaned or deleted, and there is no single source of truth.
Option C – Create a Junction object to track many-to-many relationship sounds technically correct at first, but it is massive overkill and breaks native Salesforce functionality. You would have to build a custom object (e.g., “Contractor Assignment”), write roll-up summaries, rebuild related lists, lose standard features like Contact roles on Opportunities/Cases, lose email uniqueness, lose merge functionality, and create endless custom reports. Salesforce already solved this exact use case with the native “Contacts to Multiple Accounts” feature in 2018 — using a junction object for people-to-company relationships is anti-pattern and explicitly discouraged by Salesforce architects.

Therefore, only Option D – Enable Contacts to Multiple Accounts delivers one Contact, unlimited historical agency relationships with start/end dates, full native functionality, no duplicates, and zero custom development. It is the only option that actually preserves historical accuracy while keeping everything standard and maintainable.

Explanation:

A. Create a new report folder with viewer access.
When multiple users have edit or manage access to a report folder, they can modify or delete the reports inside. This can lead to inaccurate data on dashboards that rely on those reports.
By creating a new report folder and setting access to “Viewer”, you ensure that:

- Users can view and run the reports.
- They cannot edit, save, or delete the reports.
- Dashboards using these reports still function correctly since the source reports remain unchanged.

This approach helps protect the original report structure, filters, and metrics from being altered by other users.
Administrators or report owners retain edit privileges in their own folder, but other users only have read-only visibility.
🔹 In short: “Viewer access” = users can see and use reports, but can’t modify them.

C. Move the dashboard reports to the view-only folder.
Salesforce allows you to store reports and dashboards in folders that control who can view, edit, or manage them.
A view-only folder (a folder where users have Viewer access) is ideal for reports that serve as the official data source for dashboards, because:

- Users cannot edit filters, groupings, or fields.
- Dashboards will always show consistent, verified data.
- Only designated admins or analysts can update these reports when necessary.

This ensures data consistency across dashboards — all users see the same validated information, and no one accidentally breaks or changes a source report.
🔹 In short: Move important reports to a folder that is accessible but not editable.

❌ Incorrect Options
B. Move the dashboard to the user’s private folder.
Moving the dashboard to a private folder would:

- Make it visible only to the dashboard owner (and admins).
- Prevent executives and other users from viewing it.

This option doesn’t address the real issue (source report changes).
The problem is with report editing permissions, not dashboard visibility.
🔹 In short: It hides the dashboard — it doesn’t protect the report.

D. Change the dashboard to be a dynamic dashboard.
A dynamic dashboard displays data as if you’re logged in as another user (for example, “Run as logged-in user” instead of “Run as specific user”).
This affects data visibility and sharing, not report editing permissions.
Dynamic dashboards don’t prevent anyone from editing the underlying reports — users can still open and modify the report if they have edit access.
🔹 In short: Dynamic dashboards control what data is shown, not who can edit the reports.

Reference:
Salesforce Help: Share and Manage Reports and Dashboards in Folders.
Trailhead Module: Reports & Dashboards for Lightning Experience → Control Access to Reports and Dashboards
Salesforce Best Practices: Use folders with “Viewer” or “Editor” permissions to manage who can edit or view reports.