Select Two (Multi-Select) Questions

Allow users to set up a Default Account Team to quickly add members to their accounts.

Account Teams support a Default Account Team setting, letting owners automatically add a predefined set of members to accounts they own. This satisfies the stem's capability requirement by removing repetitive manual member addition for each new account.

Grant flexible read or read/write access to related accounts, contacts, opportunities, and cases.

Account Team members receive configurable access to the account plus its related contacts, opportunities and cases, at either read-only or read/write level. This satisfies the stem's capability requirement, since access is granted per member rather than through org-wide sharing rules.

Track different functional roles such as Account Manager, Executive Sponsor, or Technical Architect.

Account Teams let members be assigned defined roles, so functional positions such as Account Manager, Executive Sponsor or Technical Architect are recorded per account. This directly satisfies the stem's requirement to track distinct functional roles across the account team.

Secure active executive sponsorship to visibly communicate the vision and importance of the project.

Visible executive sponsorship satisfies the stakeholder-engagement constraint: leaders actively communicate the vision and reinforce why Lightning Experience and forecasting matter. Without that authority behind the message, resistance hardens and adoption stalls, so this anchors the communication plan.

Celebrate early wins and share success stories of teams leveraging the new features.

Celebrating early wins reinforces adoption by showing tangible results from Lightning Experience and forecasting. Peer success stories reduce scepticism more effectively than top-down messaging, satisfying the plan's need to build momentum and demonstrate value throughout the rollout.

Communicate milestones, training schedules, and 'WIIFM' (What's In It For Me) regularly.

Regular communication of milestones, training schedules and WIIFM addresses the awareness and readiness constraint. Reps adopt Lightning Experience and forecasting only when they understand what changes, when training happens, and how it benefits them personally, so this sustains engagement across the rollout.

Regional ERP or legacy system integration dependencies

Regional ERP or legacy system integration dependencies must be assessed because each region's existing systems dictate data flows, middleware requirements and cutover sequencing, directly shaping the global rollout's integration architecture and timeline before build starts.

Multi-currency, localization, and regional date/number formatting requirements

Multi-currency, localisation and regional date/number formatting determine org-wide settings such as currency management, locale defaults and translation workstreams, which must be scoped during pre-rollout readiness because they affect the shared data model and every regional user's experience.

Local data privacy regulations and compliance requirements (e.g., GDPR, local residency laws)

Local data privacy regulations and residency laws dictate where data may be stored, who can access it and what consent mechanisms are needed, so evaluating them during pre-rollout readiness prevents compliance breaches and rework once the global Sales Cloud rollout goes live.

The ongoing maintainability of the solution by the client's internal Salesforce administrators.

Maintainability determines whether the client's admins can sustain the routing after go-live. Standard Lead Assignment Rules are declarative and admin-editable, whereas Flow-based routing offers greater flexibility but higher complexity, so this factor directly influences the build-versus-configure decision.

The complexity of the routing logic, such as multi-tier skill matching and dynamic load balancing.

Multi-tier skill matching and dynamic load balancing exceed the capabilities of standard Lead Assignment Rules, which evaluate a single criteria-based matrix. This complexity demands Flow-based routing, so evaluating the routing logic's sophistication directly determines which tool satisfies the client's automated distribution requirement.

Creating custom prompt templates infused with CRM merge fields and Apex grounding.

Prompt Builder lets admins build reusable prompt templates that merge CRM record fields and ground responses in Apex-defined data, satisfying the stem's capability requirement. This grounding constrains generative output to trusted Salesforce data rather than relying on the model's general knowledge.

Populating specific CRM record fields using field generation prompt templates.

Field generation prompt templates let users populate specific CRM record fields directly from generated output, satisfying the stem's capability requirement. This writes AI-generated values back into Salesforce objects, distinguishing it from free-text email drafting or template creation.

Generating personalized sales emails using customer and opportunity context.

Prompt Builder generates personalised sales emails by injecting customer and opportunity context from CRM records into the prompt, satisfying the stem's capability requirement. This lets sellers produce relevant outreach grounded in actual deal data rather than generic model output.

Campaign Hierarchy to roll up metrics across parent and child campaigns.

Campaign Hierarchy rolls child campaign metrics up to parent campaigns, aggregating responses, revenue and costs across related initiatives. This satisfies multi-touch attribution and ROI tracking by letting Northern Trail Outfitters report performance at programme level rather than per isolated campaign.

Campaign Member Status values to track engagement stages (e.g., Sent, Responded).

Campaign Member Status values record each member's progression through engagement stages such as Sent and Responded. This satisfies attribution tracking by capturing granular touchpoint responses per campaign, which influence models later use to assign revenue credit across the buying journey.

Campaign Influence models to attribute revenue across multiple touchpoint campaigns.

Campaign Influence models assign revenue credit across multiple campaigns touching an opportunity, using customisable models rather than single-source attribution. This directly satisfies the multi-touch attribution requirement, letting Northern Trail Outfitters measure each campaign's true contribution to closed revenue.

Einstein Opportunity Scoring to evaluate win probability on open deals.

Einstein Opportunity Scoring applies predictive analytics to open deals, generating a win-probability score from historical patterns. This directly satisfies the pipeline accuracy requirement by surfacing which opportunities are likely to close, letting management forecast with data rather than rep sentiment.

Einstein Activity Capture to automatically log emails and calendar events.

Einstein Activity Capture syncs emails and calendar events into Salesforce automatically, removing manual logging gaps. This satisfies the pipeline visibility requirement because complete, timely activity data feeds the scoring models and gives management an accurate view of rep engagement on open deals.

Perform user shadowing sessions to observe day-to-day sales activities and workflows.

Shadowing lets the consultant directly observe actual sales workflows, revealing process steps and pain points users cannot articulate. It satisfies the stem's requirement to gather existing sales process requirements, exposing real behaviour and data-entry habits rather than reported or assumed practice.

Analyze legacy system reports, data schemas, and existing documentation.

Legacy reports, schemas and documentation expose actual field structures, data volumes and integration touchpoints. This satisfies the stem's data quality and integration requirement, since schemas reveal duplicates, nulls and external system interfaces that interviews alone would miss.

Conduct facilitated requirement-gathering workshops with cross-functional stakeholders.

Facilitated cross-functional workshops bring sales, operations and IT together to capture process, data and integration requirements collaboratively. This satisfies the stem's comprehensive discovery requirement, resolving conflicting stakeholder views and validating end-to-end touchpoints in one structured session.

Amount.

Amount supplies the monetary value that Expected Revenue multiplies by probability, so it directly satisfies the calculation requirement. Without a populated Amount field, the rollup cannot produce a figure, regardless of probability or close date. This makes Amount one of the two essential fields the stem demands.

Probability.

Probability supplies the likelihood weighting that Expected Revenue multiplies against the opportunity's estimated value, satisfying the stem's requirement for an essential calculation field. Without it, the figure would be a raw amount rather than a forecast, so Microsoft Dynamics 365 treats probability as a mandatory input alongside the estimated revenue amount.

Account Teams and Opportunity Teams

Account Teams and Opportunity Teams model shared ownership across a territory, letting multiple users collaborate on one account or deal with defined roles and access. This reflects territory-based selling where several reps contribute to the same customer.

Enterprise Territory Management

Enterprise Territory Management models territory hierarchy independently of the role hierarchy, letting Universal Containers assign accounts to territories by geography or segment while preserving separate sharing and forecasting structures. This directly satisfies the territory-based sales management requirement, since territory alignment drives record access and reporting without restructuring the org's user roles.

Summary.

Summary reports group and subtotal records by row, giving totals per category without column-and-row cross-tabulation. Sales Cloud supports them alongside Tabular and Matrix formats, so Summary is one of the three report types the stem asks for.

Tabular.

Tabular reports present data as a simple flat table of rows and columns with no grouping, subtotalling or charting. Sales Cloud offers Tabular alongside Summary and Matrix, making it one of the three report types the question requires.

Matrix.

Matrix reports group records by both rows and columns, producing a cross-tabulated grid with subtotals at each intersection. Sales Cloud supports Matrix together with Tabular and Summary, so it satisfies the stem's request for three report types.

Data quality metrics (e.g., completeness of key fields, duplicate rates)

Data quality metrics such as field completeness and duplicate rates reveal whether the CRM's underlying information is trustworthy. Poor data undermines forecasting and reporting, so tracking these ensures the implementation delivers reliable insight, not just activity.

User adoption metrics (e.g., login frequency, active user counts)

User adoption metrics like login frequency and active user counts show whether reps actually use Sales Cloud. Without adoption, process and revenue gains never materialise, so these metrics confirm the system is embedded in daily selling behaviour.

Business outcome and ROI metrics (e.g., win rates, sales cycle length)

Business outcome and ROI metrics quantify realised value after go-live, such as win rates and sales cycle length, satisfying the stem's requirement for a balanced evaluation rather than adoption-only measures. They prove whether Sales Cloud actually improved selling performance, complementing user adoption and process metrics.

The probability values for each stage.

Probability values assigned to each stage directly drive weighted revenue forecasting, so they must be defined when designing the sales process. This satisfies the stem's design requirement by ensuring stage progression reflects realistic close likelihoods, enabling accurate pipeline reporting and consistent qualification criteria across the organisation's opportunity stages.

Which record types will use the process.

Record types determine which page layouts, picklist values and sales processes apply to different opportunity types, so deciding which record types use the process is essential before defining stages. This satisfies the stem's design factor by ensuring the process maps to the correct opportunity variants.

The stages required for the sales cycle.

The stages required for the sales cycle define the sequential steps an opportunity progresses through, forming the backbone of the sales process. This satisfies the stem's design factor by ensuring the process reflects the actual buying journey and stage-gate criteria.

Add both Leads and Contacts directly to the Campaign using the 'Add Members' button from the Campaign record.

Campaigns accept both Leads and Contacts as Campaign Members, so the 'Add Members' button lets the team attach either record type to one Campaign and assign each a Campaign Member Status, satisfying the single-Campaign requirement.

Customize Campaign Member Status values to track specific response milestones for both Leads and Contacts.

Customising Campaign Member Status values lets the administrator define response milestones that apply to every Campaign Member record, regardless of whether the member is a Lead or a Contact. Because Campaign Members store both object types in one related list, the same status picklist tracks responses for both, satisfying the requirement to monitor Leads and Contacts against a single Campaign.

Load parent records (Accounts) before child records (Contacts and Opportunities).

Loading Accounts first satisfies the lookup relationship dependency, since Contacts and Opportunities reference the Account parent. Child records cannot resolve their AccountId until the parent exists, so this ordering prevents orphaned or failed rows during migration and preserves referential integrity across the three objects.

Use External IDs to map relationships between related objects during upsert operations.

External IDs let upsert operations match records across Accounts, Contacts, and Opportunities without relying on Salesforce record IDs, which differ between source and target orgs. This preserves parent-child relationships during migration, directly satisfying the data integrity requirement by preventing orphaned or duplicated records when loading related objects.

Perform a test migration in a full or partial sandbox environment first.

A sandbox rehearsal exposes mapping errors, validation rule failures and trigger side effects before production data is touched. Running the full migration there first protects live records and confirms the strategy meets the integrity requirement.

Qualitative adoption and engagement metrics (e.g., active user ratios, feature utilization)

Qualitative adoption and engagement metrics, such as active user ratios and feature utilisation, reveal whether users genuinely embrace Sales Cloud rather than merely logging in. Combined with quantitative business metrics, they give a comprehensive picture of programme success, satisfying the requirement for essential measurement categories.

Quantitative business outcome metrics (e.g., win rate, sales cycle length, pipeline velocity)

Win rate, sales cycle length and pipeline velocity are lagging indicators that directly quantify revenue impact, satisfying the stem's demand for comprehensive success measurement. Qualitative adoption or satisfaction metrics alone cannot demonstrate commercial return, so pairing these quantitative business outcomes with adoption measures gives the balanced view the client requires.

Analyzing system adoption dashboards and feature utilization reports to track active usage.

Adoption dashboards and feature utilisation reports quantify active usage, logins and which capabilities reps actually use, evidencing whether the deployed functionality is embedded in daily selling. This measures realised behavioural change against the intended business outcomes, not merely technical delivery.

Comparing pre-implementation sales cycle lengths and win rates against current post-go-live metrics.

Comparing pre-implementation sales cycle length and win rate against post-go-live figures provides objective before-and-after evidence of business benefit. These metrics directly test whether the deployment improved sales performance, satisfying the audit's requirement to evaluate achieved business outcomes.

Sales Managers who oversee day-to-day pipeline execution and team coaching

Sales managers own pipeline execution and coaching, so their involvement secures frontline adoption and defines practical success metrics. Engaging them during pre-rollout planning satisfies the stem's requirement to build buy-in and shape measurable outcomes before go-live.

Executive Sponsors providing budget and strategic direction

Executive sponsors control budget and strategic direction, so their engagement secures funding and aligns the rollout with business objectives. This satisfies the stem's requirement to obtain project buy-in and define success criteria at the planning stage.

Frontline Sales Representatives who perform daily CRM data entry

Frontline representatives perform daily CRM data entry, so their input exposes usability gaps and drives adoption. Engaging them during pre-rollout planning satisfies the stem's requirement to secure buy-in and define realistic success measures grounded in actual usage.

Detailed admin handover training sessions and recorded walkthroughs of complex custom configurations.

Recorded walkthroughs and admin training sessions directly satisfy the sustainability constraint by transferring operational knowledge to the client's team, enabling them to maintain complex custom configurations independently after the consultant disengages. This reduces reliance on external support and preserves institutional knowledge, ensuring the solution remains manageable long-term without the original implementer.

Complete technical documentation, including data models, configuration logs, and custom code inventories.

Complete technical documentation satisfies the sustainability constraint by preserving the system's design rationale for future administrators. Data models, configuration logs and custom code inventories let successors trace why objects, automations and integrations were built as they were, enabling safe modification without the original consultant. This directly supports long-term maintainability after handover.

An integration architecture diagram mapping all external systems, middleware endpoints, and data flows.

Maps every external system, middleware endpoint and data flow, giving the client's support team the reference needed to troubleshoot integrations independently after handover. This directly satisfies the sustainability requirement by removing reliance on the consultant's undocumented knowledge.

Assess the impact of the requested changes on project timeline, budget, and resource allocation.

Assessing impact on timeline, budget and resources quantifies the consequences of the scope changes against the hard deadline. This evidence is essential before any approval decision, ensuring the steering committee can judge whether the go-live date remains achievable.

Present the Change Request to the executive steering committee or change control board for decision.

Escalating the Change Request to the executive steering committee or change control board places the approval decision with the authority that owns the hard deadline. Formal change management requires this governance step before any scope alteration is accepted or rejected.

Document the requested changes in a formal Change Request (CR) log detailing scope, impact, and cost.

Documenting the request in a formal Change Request log captures scope, impact and cost, creating the auditable record formal change management demands. This written artefact underpins impact assessment and gives the change control board the evidence needed to decide.