Explanation:
To share dashboard components directly in Chatter, the administrator must enable dashboard feed tracking. This feature allows users to follow dashboards and post dashboard components (charts, metrics, tables) to Chatter feeds, where team members can comment, like, and discuss the data. This is a declarative setting that must be turned on at the dashboard level or via setup.

Correct Option: D

Enable dashboard feed tracking allows users to post dashboard snapshots or individual components to Chatter.

Once enabled, a "Post to Chatter" button appears on dashboard components.

Management can share insights with their team without leaving Salesforce.

No code or custom development required.

Incorrect Option: A

Reporting snapshots are scheduled report exports stored as custom objects; they are not related to Chatter or sharing dashboard components.

Completely different feature for historical trend reporting.

Incorrect Option: B

Select Download Chart downloads a chart as an image file (PNG), but this does not share directly to Chatter.

A user would have to manually save the file and upload it to Chatter, which is not the native integration described.

Not the intended functionality for Chatter sharing.

Incorrect Option: C

Set View Dashboard As to the dashboard viewer (dynamic dashboard) controls data visibility based on the logged-in user, not the ability to share components to Chatter. Irrelevant to the requirement.

Reference:
Salesforce Help Article: Share Dashboard Components in Chatter – Enable dashboard feed tracking to allow users to post dashboard components to Chatter feeds. Download Chart exports an image but does not post to Chatter. Reporting snapshots and dashboard viewing settings are unrelated.

Explanation:

This question tests understanding of Salesforce lead conversion behavior and what happens to associated records during the process. When a lead is converted, Salesforce automatically maps and transfers related data to the newly created or matched Contact, Account, and Opportunity records in a structured way.

✅ Correct Option:

C. All Activities are Attached to the Resulting Contact, Account, and Opportunity Records — During lead conversion, Salesforce transfers both open and closed activities (tasks and events) to the resulting Contact, Account, and Opportunity. This ensures complete interaction history is preserved and accessible on the converted records, maintaining full visibility of all past and pending engagements without any data loss.

❌ Incorrect Options:

A. Records from Custom Objects are Attached to the Resulting Contact, Account, and Opportunity Records — Custom object records are not automatically transferred during lead conversion. Salesforce does not natively relate custom object data to converted records unless custom development or configuration is explicitly built to handle this mapping separately.

B. Open Activities Only are Attached to the Resulting Contact, Account, and Opportunity Records — This is partially correct but incomplete. Salesforce transfers both open and closed activities during conversion, not just open ones. Limiting the statement to open activities only misrepresents the full scope of what Salesforce moves during the lead conversion process.

D. Campaign History is Attached to the Resulting Contact, Account, and Opportunity Records — Campaign history from a converted lead is transferred only to the resulting Contact record, not to the Account or Opportunity. Stating it attaches to all three records is inaccurate and does not reflect Salesforce's standard lead conversion behavior.

🔧 Reference:
→ Salesforce Help – Convert Qualified Leads
Confirms that all activities (open and closed) are reassigned to the resulting Contact, Account, and Opportunity upon lead conversion.

→ Salesforce Help – What Happens to Related Records After Lead Conversion
Clarifies how campaign history, activities, and other related data are handled specifically during the lead conversion process.

Explanation:
The administrator wants to understand the current state of data quality and record completeness (e.g., which records are missing key fields). Creating a report for Accounts and Opportunities that highlights missing data (e.g., filter by "Key Field equals null") gives visibility into the problem. This allows the administrator to assess the extent of incomplete records before taking corrective actions like making fields required or exploring AppExchange solutions.

Correct Option: B

A report can show records where key fields are blank, providing a clear picture of data quality gaps.

Can be filtered by owner, date, or other criteria to identify patterns.

This is the first step in understanding scope and severity of incomplete data.

No changes to system behavior required initially.

Incorrect Option: A

AppExchange solutions might be useful after understanding the problem, but the administrator first needs to assess the current state.

Installing a third-party tool without knowing the specific gaps is premature.

Option B provides immediate, native insight.

Incorrect Option: C

Subscribing reps to a monthly report might help with ongoing awareness, but it does not help the administrator understand the current data quality state.

It shifts responsibility to reps without first assessing the problem.

Not the correct first diagnostic step.

Incorrect Option: D

Configuring key fields as required prevents future missing data but does nothing to help the administrator understand the current state of existing records.

This is a corrective action, not a diagnostic one.

Should be done after understanding the problem, not before.

Reference:
Salesforce Help Article: Monitor Data Quality with Reports – Create reports with null filters to identify records missing key fields. This gives visibility into data completeness before implementing solutions like required fields or AppExchange tools. Subscriptions and third-party tools are secondary diagnostic or corrective steps.

Explanation:
Even though the Case object has Organization‑Wide Defaults (OWD) set to Private, a dashboard can show data that reps would not normally see if the dashboard's running user has broader access (e.g., a manager or system administrator). When the running user has "View All Data" or higher object permissions, all dashboard viewers see data through that user's permissions, bypassing individual record‑level security.

Correct Option: C

Dashboard's running user determines the data visibility for all viewers of that dashboard.

If the running user is a manager or admin with "View All Cases," reps will see all cases on the dashboard regardless of OWD Private.

This is a common misconfiguration causing unintended broad access.

Solution: Set running user to "Logged‑in user" (dynamic dashboard) or use a running user with restricted access.

Incorrect Option: A
Dashboard Filters control which data subset appears within a dashboard, but they do not override the running user's base permissions.

Filters cannot grant access to records the running user cannot see.

Not the cause of inappropriate access.

Incorrect Option: B

Public Dashboards refers to dashboard folders with public access, which controls who can view/edit the dashboard folder, not the data visibility within the dashboard.

A public folder does not bypass OWD or running user permissions.

Irrelevant to the issue.

Incorrect Option: D

Dashboard Subscriptions send email snapshots of dashboards; they do not affect what data users see when viewing the dashboard live.

Subscriptions respect the same running user logic.

Not the cause.

Reference:
Salesforce Help Article: Dashboard Running User and Data Visibility – Dashboard data is shown based on the running user's permissions, not the viewer's. To restrict data per viewer, set running user to "Logged‑in user." Running users with broad access can expose private data on dashboards. OWD alone does not limit dashboard visibility.

Explanation:

This question tests the administrator's ability to recommend the most efficient user interface for managing a sales pipeline. The requirement specifies a "visual way" to see "all deals at once" while allowing for "quick movement" between stages, which points toward an interactive and graphical representation of list data.

🔴 Option A: Set up opportunity reports
Reports are excellent for high-level data analysis and historical tracking. However, they are static documents. While you can group data by stage and add charts, reports do not allow sales reps to "quickly move" opportunities forward through a drag-and-drop interface, making them a viewing tool rather than a management tool.

🔴 Option B: Create a custom dashboard
Dashboards provide a great bird's-eye view of the pipeline using various charts and metrics. Like reports, they are designed for visibility and monitoring rather than day-to-day record manipulation. A user cannot interact with a dashboard component to change the stage of an individual deal, failing the requirement for quick progress tracking.

🟢 Option C: Use the Kanban view
This is the correct feature because it transforms a standard list view into a visual board where opportunities are organized in columns by stage. It allows users to see all deals simultaneously, view key card fields, and—most importantly—quickly move deals forward by dragging and dropping them from one column to the next.

🔴 Option D: Configure opportunity list views
A standard list view provides a table-based summary of records and can be filtered. While useful for sorting data, the traditional row-and-column format is not considered a "visual way" to manage a pipeline in the same sense as a Kanban board, and it requires manual field editing rather than a quick drag-and-drop action.

🔧 Reference:
→ Salesforce Help: Kanban View
This official Salesforce Help topic confirms how users can use the Kanban view to visually manage records and update fields via drag-and-drop.