Explanation:

The Path feature in Salesforce is purpose-built to guide users through a business process — especially on objects like Opportunity, Lead, and Case. It’s ideal for sales teams who need:

📌 Key fields highlighted at each stage of the sales process
💡 Guidance for Success — tips, strategies, and recommendations tailored to each stage
🎯 A visual representation of progress using a chevron-style layout

In this scenario, the sales manager wants to standardize data collection and provide stage-specific guidance. Path delivers exactly that.

🔍 Why the other options don’t fit:
A. Workflow
Used for automation (e.g., field updates, email alerts), not for guiding user input or displaying recommendations.
C. Chatter feed
Good for collaboration, but not structured or stage-specific. Doesn’t enforce data collection or show key fields.
D. Global Action
Useful for creating records quickly, but not tied to specific stages or processes on the Opportunity record.

🔗 References:
Salesforce Help: Guide Users with Path
Salesforce Ben: Enable Salesforce Path in 6 Easy Steps

Explanation:

A. Global actions can be accessed anywhere actions are pages, feed and Chatter groups.
The key benefit of a global action is its universal accessibility. Unlike an object-specific action that only appears on a particular object's record page, a global action can be placed in various locations. On mobile, this includes the action bar that appears on many pages, allowing users to send an email without navigating to a specific Lead, Contact, or Account record.

Incorrect answers

B. Salesforce Lightning Component Library houses existing global actions prebuilt for use.
The Lightning Component Library is for prebuilt components, not prebuilt actions. While there are standard actions, the library is not the repository for managing them.

C. The global action's layout automatically clones the default page layout.
Global actions have their own dedicated page layouts that are configured independently of an object's page layout. This allows the app builder to create a simplified, mobile-friendly layout with only the necessary fields, which is often a different configuration than the default page layout.

D. Global actions are record-specific and are available when searching that particular object.
This describes an object-specific action, not a global one. Global actions are not tied to a single record or object. They are available across multiple objects or even when not on a record page at all, such as on the Home page.

Explanation:

The solution that an app builder should use to meet this requirement is creating a custom report type with converted leads as the primary object.
A custom report type is a template that defines the objects and fields that are available for a report. The app builder can create a custom report type that has converted leads as the primary object and includes fields from related objects, such as accounts, contacts, and opportunities. This way, sales reps can create reports on converted leads and see their related information.

Option A is incorrect because enabling preserve lead status in the lead conversion settings does not affect the reporting on converted leads, but rather allows users to retain the original lead status after conversion.

Option B is incorrect because assigning the representative view and edit converted leads permission does not affect the reporting on converted leads, but rather allows users to view and edit converted lead records.

Option C is incorrect because ensuring the representative has read access to the original lead records does not affect the reporting on converted leads, but rather allows users to view the original lead records.

Explanation:
In a private sharing model for Accounts in Salesforce, access to records is restricted to the record owner, users higher in the role hierarchy (if enabled), or users granted access through manual sharing, sharing rules, teams, or other configurations. Since User A can view the Account record owned by User C, but User B receives an "insufficient privileges" error, and both users have the same role in the role hierarchy as User C, the difference in access must stem from specific sharing mechanisms or permissions granted to User A but not User B. Let’s evaluate each option:

Option A: Correct.
User A could be on the same Account Team as User C. Account Teams allow specific users to be granted access to an Account record with defined permissions (e.g., Read or Read/Write). If User A is part of the Account Team for the record owned by User C, they would have access, while User B, who is not on the team, would not. This is a plausible reason for the difference in access.

Option B: Incorrect.
The question specifies that User A and User B have the same role in the role hierarchy as User C, but it does not explicitly state they have different profiles. While different profiles could theoretically cause a difference in access (e.g., through object-level permissions), the private sharing model focuses on record-level access, and the question implies the issue is related to sharing rather than profile permissions. Without evidence that profiles differ, this is not a strong reason.

Option C: Correct.
User C could have manually shared the Account record with User A. Manual sharing allows the record owner (User C) to explicitly grant access to specific users, such as User A, with Read or Read/Write permissions. If User C did not manually share the record with User B, this would explain why User B cannot access the record.

Option D: Incorrect.
A permission set typically grants additional object-level or field-level permissions, not record-specific access in a private sharing model. Since the question focuses on access to a specific Account record and both users have the same role, a permission set is unlikely to be the reason for the difference in access, as it does not typically override record-level sharing restrictions.

Option E: Correct.
User A could be part of a public group that has been granted access to the Account record via a sharing rule. Sharing rules can extend access to users in public groups, roles, or roles and subordinates based on criteria (e.g., record ownership or field values). If a sharing rule grants access to a public group that includes User A but not User B, this would explain why User A has access while User B does not.

Key Considerations:
In a private sharing model, record access is determined by ownership, role hierarchy, manual sharing, sharing rules, or teams.
The question notes that User A and User B have the same role as User C, so role hierarchy does not grant additional access (since they are at the same level).
The reasons must specifically explain why User A has access to User C’s record while User B does not, pointing to record-level sharing mechanisms like Account Teams, manual sharing, or sharing rules.

References:
Salesforce Documentation: Sharing Model Overview
Salesforce Help: Manual Sharing
Salesforce Help: Account Teams
Trailhead: Data Security Module – Explains sharing rules, manual sharing, and teams.

Explanation:

The solution that should meet this requirement is updating the support team profile to remove the Bronze record type. This way, the support team users will not be able to create new cases with the Bronze record type, as it will not appear in their record type selection list.

Option A is incorrect because updating the organization-wide defaults to private for Case does not affect the record type availability, but rather the record access level.
Option C is incorrect because creating permission set group for Case that includes Platinum and Diamond record types does not prevent the support team users from creating new cases with the Bronze record type, as they may still have access to it through their profile.
Option D is incorrect because making the record type hidden to support users and updating sharing roles to private does not prevent the support team users from creating new cases with the Bronze record type, as they may still have access to it through their profile.