Explanation:

Why B is Correct:
1. The requirement is to track the same data (number of retail locations) from Lead to Account after conversion.
2. Salesforce allows field mapping during lead conversion to automatically pass custom field values from the Lead object to the Account (or Contact/Opportunity) object.
3. This ensures the sales and service teams see the retail location count seamlessly post-conversion without manual updates.

Reference:
Salesforce Lead Conversion Field Mapping

Why A is Incorrect:
A custom object for retail locations is overkill for a simple count and doesn’t address the need to preserve the data during conversion.
It would require additional automation (e.g., Flow) to sync data, which is unnecessary for this use case.

Why C is Incorrect:
Roll-up summaries only work on master-detail relationships, which Leads don’t support.
Even if a custom object existed, roll-ups wouldn’t solve the mapping requirement during conversion.

Additional Notes:
Implementation Steps:
Create a custom number field on both Lead and Account objects (e.g., "Number of Retail Locations").
In Setup > Lead Conversion > Field Mapping, map the Lead field to the Account field.
After conversion, the Account will inherit the value automatically.

Explanation:

The core issue is about sharing access to Contact records. In Salesforce, Contacts are separate objects with their own Organization-Wide Default (OWD) sharing settings. Even if a user can see an Account, they may not automatically see the Contacts related to that Account.
Account Teams are a powerful sharing tool. When you add a user to an Account Team, you can grant them specific object-level permissions for that particular Account and its related records.
One of these configurable permissions is "Read" access to Contacts. By adding the Opportunity owner to the Account Team and selecting this permission, the Account owner can selectively grant that user read access to all Contacts associated with that specific Account.
This provides a precise, manual method for the Account owner to share Contacts with other users (like the Opportunity owner) on a case-by-case basis, which is exactly what the requirement asks for.

Why the Other Options Are Incorrect:
A. Add Opportunity owners to the Opportunity Team and configure Contact sharing.
Opportunity Teams control sharing for the Opportunity object and its related records (like Opportunity Contact Roles). They do not control sharing for the Account object or its related records (like Contacts).
There is no setting on an Opportunity Team that can grant access to Account Contacts. This option misunderstands the scope of the Opportunity Team sharing model.

C. Transfer Contact ownership from themselves to the Opportunity owner.
This is a drastic, incorrect, and unsustainable solution.
Ownership implies responsibility; transferring Contact ownership away from the correct owner (likely the Account owner or a marketing user) to a sales rep just for viewing rights breaks data management best practices.
It is not "selective sharing"—it is a complete transfer of responsibility and would break any role hierarchies or sharing rules based on ownership.
This process would have to be repeated manually for every single Contact and then reversed, which is highly inefficient and error-prone.

Reference:
Salesforce Help: Account Teams

Key Concept: Understanding that visibility to an Account does not automatically grant visibility to its child objects (like Contacts and Cases). Sharing must be configured for each object. Account Teams provide a manual, record-level mechanism for the Account owner to share access to related objects with other users.

Explanation:

With Salesforce Approvals, users can:
Approve/reject in-app (Salesforce).
Approve/reject via email (fastest for busy managers).
Even approve/reject from the Salesforce mobile app.
For timely approvals, email-based approvals are the most efficient and exam-preferred answer.

A. Allow managers to approve or reject requests via an email.
✅ Correct.
Salesforce Approval Processes allow email-based approvals.
Managers can click Approve/Reject links directly in the email, without logging into Salesforce.
This is a widely used best practice for timeliness and efficiency.

B. Configure Einstein Opportunity Insights to approve requests.
❌ Incorrect.
Einstein Opportunity Insights provides AI-driven guidance (e.g., follow-up reminders, at-risk deals).
It does not handle approval automation.

C. Add a dashboard of pending approvals to the Chatter feed.
❌ Incorrect.
Chatter feeds and dashboards can display approvals, but they don’t allow direct approve/reject actions.
This adds visibility, but not real efficiency in streamlining.

Salesforce Reference
Salesforce Help: Approve Requests via Email

✅ Exam Tip:
If the question asks about efficiency / timeliness for managers, think email or mobile approvals.

Explanation:

Before initiating any data migration into Salesforce, the first and most critical step is to understand the volume and nature of the data being migrated. This includes:

How many records are involved (Accounts, Contacts, Leads, Campaigns, etc.)
What types of data are included (structured, unstructured, legacy formats)
Data quality and duplication risks
Mapping requirements to Salesforce objects and fields
Understanding the volume and complexity of the data helps the consultant:
Choose the right migration tools (e.g., Data Loader, Data Import Wizard, third-party ETL tools)
Plan for batch sizes, API limits, and performance considerations
Estimate migration timelines and resource needs

This foundational step ensures that the migration is scalable, accurate, and aligned with CK’s business goals.

❌ Why the Other Options Don’t Fit:
A. Number of marketing campaign licenses required
License needs are important, but they come after understanding what data is being migrated and how it will be used.
B. Role hierarchy and sharing rules
These are part of post-migration security setup, not the initial step. You need to know what data is coming in before designing access controls.

📘 Reference:
Salesforce Help: Data Migration Best Practices
Trailhead: Data Management

Explanation:

A. Capability Model
Analysis: A Capability Model is a high-level diagram that outlines the core capabilities or functions of a business, organized by areas such as sales, marketing, or customer service. It provides a strategic view of what the business does without diving into detailed workflows, making it ideal for showing the context of a new process within the overall business structure. According to Salesforce’s business process design principles (e.g., Trailhead’s Business Process Mapping module), a capability model is used to depict high-level business functions and their relationships, which aligns with the executive’s request for a diagram showing CK’s high-level processes. For example, it could show “Lead Management” or “Opportunity Tracking” as capabilities, with the new process (e.g., a lead scoring system) positioned within this framework.
Why it’s correct: A capability model provides a high-level, strategic overview of business processes, perfectly suited for contextualizing a new process for executives.

B. Value Stream Map
Analysis: A Value Stream Map is a detailed diagram that maps the flow of materials, information, and activities in a specific process, focusing on value delivery to the customer and identifying waste (e.g., Lean methodology). While useful for optimizing specific processes, it is too granular for showing the high-level context of CK’s overall business processes. Salesforce documentation and process improvement guides note that value stream maps focus on detailed workflows, not broad business overviews, making this less suitable for the executive’s request.
Why it’s incorrect: Value stream maps are too detailed and process-specific, not ideal for a high-level business context diagram.

C. Detail Process Mapping
Analysis: Detailed Process Mapping involves creating granular flowcharts or diagrams of specific processes, showing step-by-step tasks, decision points, and roles (e.g., using BPMN or flowcharts). This is useful for documenting workflows but is too low-level for the executive’s need to show the high-level business context. Salesforce’s Trailhead emphasizes that detailed process maps are for operational analysis, not strategic overviews, making this option unsuitable for the requirement.
Why it’s incorrect: Detailed process mapping focuses on specific workflows, not the high-level business structure.

Why Option A is the Best Fit:
High-Level Focus: A capability model provides a strategic, high-level view of CK’s business functions (e.g., sales, customer support), aligning with the executive’s request for a diagram showing overall processes.
Context for New Process: It allows the new process to be positioned within the broader business framework (e.g., placing a new lead qualification process under “Sales Operations”), providing clear context.

Implementation Steps:
Identify CK’s core business capabilities (e.g., Lead Generation, Opportunity Management, Customer Support) through stakeholder workshops.
Create a diagram (e.g., using tools like Lucidchart or PowerPoint) showing capabilities as boxes, grouped by business area.
Highlight where the new process fits within the capability model (e.g., “Lead Scoring” under “Lead Management”).
Validate the diagram with executives to ensure alignment with CK’s business goals.
Share the diagram in presentations or documentation to provide context for the new process.
Considerations: Ensure the model is simple and visual, avoiding excessive detail. Use Salesforce terminology (e.g., Leads, Opportunities) to align with Sales Cloud.

References:
Salesforce Trailhead: Business Process Mapping
Salesforce Sales Cloud Consultant Exam Guide
Salesforce Help: Process Design Best Practices.