Explanation:

The requirement is to analyze the average time opportunities spend in each stage. Salesforce provides a standard, out-of-the-box report type specifically designed for this purpose: the Opportunity Stage Duration report.

Let's break down each option:

C. Run the Opportunity Stage Duration report
Correct. The "Opportunity Stage Duration" report type is built to show exactly this information. It analyzes historical data from the Opportunity Field History tracked object to calculate the amount of time an opportunity spent in each stage of its sales process. Running this report is the simplest and most direct way to fulfill the request without any custom configuration.

A. Use process builder to capture the daily average on each opportunity.
Incorrect. This would be an extremely complex and inefficient solution. Process Builder is an automation tool, not an analytics tool. Trying to build a process to calculate and store a daily average for each stage on each opportunity would be cumbersome, resource-intensive, and difficult to maintain.

B. Add Formula Fields to track Stages on each Opportunity.
Incorrect. Formula fields are great for calculating values based on other fields on the same record. They cannot perform historical tracking or calculate the duration between events (like stage changes) that happen over time.

D. Refresh weekly reporting snapshots for Closed Opportunities.
Incorrect. A reporting snapshot is used to store aggregate data from a report into a custom object for historical trend analysis. It is not the right tool for calculating the time spent in individual stages. Furthermore, it would only work for closed opportunities, not for analyzing the pipeline of open opportunities.

Prerequisite: Field History Tracking
For the "Opportunity Stage Duration" report to work, the administrator must ensure that Field History Tracking is enabled for the Stage field on the Opportunity object. If it is not already enabled, this is the one configuration step required.

Reference:
Salesforce Help: "Run an Opportunity Stage Duration Report"
This documentation explains that this report type "shows how long opportunities remain in each stage" and details the prerequisite of enabling field history tracking for the Stage field.

Explanation:

A. Custom and standard objects have standard fields (✅ Correct)
Both standard and custom objects come with standard fields by default.
For example:
Every object (standard or custom) has fields like Created By, Last Modified By, Owner, and Record ID.
These fields are automatically created by Salesforce and help track record metadata.
In addition, custom objects also support the creation of custom fields, but they still include built-in standard fields that behave like those on standard objects.
So yes — both types of objects include standard fields provided by Salesforce.

B. Standard objects are included with Salesforce (✅ Correct)
Standard objects are predefined by Salesforce and come ready to use in every Salesforce org.
Examples include:
- Accounts
- Contacts
- Opportunities
- Leads
- Cases
These objects are part of the Salesforce data model out of the box and can be customized (e.g., by adding custom fields, validation rules, or page layouts), but they cannot be deleted or recreated.
So this is true — standard objects are included with Salesforce by default.

❌ Incorrect Options:
C. A new standard object can be created
This is false.
Administrators cannot create new standard objects — only Salesforce can define them.
Admins can, however, create custom objects to capture additional business data not covered by standard objects.

D. Only standard objects support master-detail relationships
This is also false.
Both custom and standard objects can participate in master-detail relationships, though there are some limitations:
- A custom object can be the child in a master-detail relationship with either a standard or another custom object.
- A standard object can never be the child in a master-detail relationship — only the parent.
So, it’s incorrect to say “only standard objects support master-detail relationships.”

Summary:
When working with Salesforce objects, remember that standard objects (like Accounts, Contacts, and Opportunities) come built into Salesforce and include standard fields by default.
Similarly, custom objects also have system-generated standard fields (such as ID, Owner, Created Date, etc.) when created.
However, new standard objects cannot be created, and both standard and custom objects can support master-detail relationships under certain conditions.

Reference:
Salesforce Help: Objects Overview
Trailhead: Data Modeling → Understand Custom and Standard Objects

Explanation:

✅ Why This Is Correct
B. Permission Sets
Permission Sets are the most flexible and scalable way to grant additional access without changing a user's profile. In this case:
- The support users need access to the Lead object (Read, possibly Create/Edit)

The administrator can:
- Create a Permission Set with Lead object permissions
- Assign it to the support users

This avoids the need to clone or modify profiles and allows targeted access for specific tasks like follow-up calls.

❌ Why These Are Incorrect

❌ A. Create a New Profile
Why It’s Incorrect:
Creating a new profile is time-consuming and rigid.
Profiles are best used for broad role definitions, not granular access tweaks.
If support users already share a profile, creating a new one just to add Lead access introduces redundancy and maintenance overhead.
Better alternative: Use a Permission Set to layer access without disrupting existing profile structure.

❌ C. Assign a New Role
Why It’s Incorrect:
Roles control record-level visibility via the role hierarchy, not object-level permissions.
Assigning a new role won’t grant access to the Lead object if the user’s profile doesn’t allow it.
Roles help with sharing rules, not with CRUD access.
Key distinction: Roles = who can see which records; Profiles/Permission Sets = what users can do with objects.

❌ D. Set Up Manual Sharing
Why It’s Incorrect:
Manual sharing allows users to share specific records, but only if they already have access to the object.
If support users don’t have access to Leads, they can’t even see or share Lead records.
It’s a record-level tool, not a solution for object-level access.
Bottom line: You can’t share what you can’t access.

✅ Recap: Best Practice
Use a Permission Set to:
- Grant Read/Create/Edit access to the Lead object
- Apply it to only the support users who need it
- Avoid modifying profiles or roles unnecessarily

Reference Links
Salesforce Help: Permission Sets Overview
Trailhead: Control Access to Objects

Explanation:

Why C Is Correct
Enable Forecasting
Forecasting is the only native Salesforce tool that predicts upcoming revenue by fiscal quarter, rolls up rep commitments, and lets the Sales Director:
- See projected revenue for Q1, Q2, Q3, Q4+
- Compare committed, best case, and pipeline forecasts
- Set quarterly goals per rep or team
- Benchmark rep performance vs. quota
Setup (2 minutes):
- Setup → Forecast Settings → Enable Forecasting
- Choose Opportunity Amount or Product Revenue
- Set Fiscal Year and Quarterly Periods
- Assign Forecast Roles (Director sees rollups)
- Done — Director gets a real-time revenue prediction dashboard.

Why D Is Correct
Configure Opportunity Stages with Probabilities
Forecasting relies 100% on Stage → Probability mapping.
Without accurate Stage probabilities (e.g., Proposal = 70%, Negotiation = 90%), forecasts are garbage.
The admin must:
- Define closed-won/lost stages
- Assign realistic % probabilities
- Lock them per Sales Process
This ensures pipeline math is correct when Forecasting rolls up expected revenue.

Why the Other Options Fail
Option A – Sales Quotes
Sales Quotes is a red herring that fails completely. Quotes are for pricing and approvals — they have zero impact on revenue forecasting, goal setting, or rep benchmarking. Even with CPQ, quotes don’t feed Forecasting unless tied to Opportunities (which still need Stages and Forecasting enabled). This is a classic exam trap.

Option B – Opportunity List View
Opportunity List View is useless for prediction. A list view shows current open opps — it does not roll up, project future quarters, set goals, or benchmark reps. It’s a static view, not a forecasting engine. The Director would have to manually sum amounts — no automation, no accuracy.

Reference
“Enable Forecasting to predict revenue across fiscal periods and set quarterly goals. Accurate Stage probabilities are required for reliable forecast calculations.”
— Salesforce Help: Set Up Forecasting

Verification Steps
- Enable Forecasting → Go to Forecasts tab
- See Q1, Q2, Q3, Q4+ columns with Committed, Best Case, Pipeline
- Set Rep Quota = $500K/Q → See % to Goal
- Change an Opp from Proposal (70%) → Negotiation (90%) → Forecast instantly updates
- Director sees team rollup and rep performance vs. goal

Explanation:

Salesforce controls the visibility of tabs (the objects or pages users can access from the navigation bar or App Launcher) through Tab Settings in a user’s profile or permission set.

Each tab in Salesforce can be configured in a profile with one of three visibility settings:
- Default On: The tab is visible in all apps where the object is included.
- Default Off: The tab is available but not automatically visible in apps; users can add it manually.
- Tab Hidden: The tab is completely hidden from all apps and the App Launcher — however, users can still access the underlying records via:
- Related lists,
- Reports,
- Global search,
- Record links.

So, when a tab is hidden, the tab itself is not displayed in the interface, but object permissions still apply — meaning that if the user has permission to view the records (via object and field-level security), they can still see those records even though the tab doesn’t appear in the UI.

❌ Incorrect Options:
A. Object Permissions
Object permissions (Create, Read, Edit, Delete, View All, Modify All) determine what actions users can perform on records of an object. They do not control tab visibility. A user can have read access to an object but still not see the tab if the tab is hidden via tab settings.

B. App Permissions
App permissions control specific functional access within Salesforce (like “Manage Users” or “View Setup and Configuration”). They don’t affect tab visibility.

C. Org-Wide Defaults (OWD)
Org-Wide Defaults define the baseline record-level access (Public Read Only, Private, etc.) across the organization. They control who can see or edit records, not whether the tab for that object appears in an app.

Summary:
The Tab Settings on a profile determine whether a tab is visible or hidden in the Salesforce App Launcher or in specific apps. When a tab is set to Hidden, users don’t see it in the interface, but they can still access records if their object-level and record-level permissions allow it. This makes tab settings an excellent tool for simplifying the user interface while maintaining access to necessary data. Object permissions or OWDs do not influence tab visibility — only what data a user can act upon.

Reference:
Salesforce Help: Customize Application Tabs in Profiles
Trailhead: Control Access to the Salesforce Platform → Customize Profiles and Permission Sets