Overview
Consulting and Implementation Strategies is the heaviest of the five Sales-Con-201 sections and holds five objectives. It looks at the work around configuration rather than the configuration itself, following a project from the first discovery workshop to the months after go-live.
Before build, you assess user experience, plan communication and training, prepare change management and agree on success metrics. During build, you choose sandbox types, release approaches and deployment tools that reduce risk. After launch, you respond to low adoption, shifting requirements and access requests, and set up a cycle of continuous improvement. Two further objectives cover project management across the lifecycle, keeping scope and timeline under control, and the discovery skills of running workshops, analyzing requirements, defining solutions and prioritizing use cases with stakeholders.
How it's tested
Scenarios describe a project at a specific stage: a kickoff with conflicting stakeholder wishes, a build running late, a go-live with poor login numbers. You choose the consulting action that fits that stage. Wrong answers are often reasonable activities placed at the wrong point, or technical fixes for what is really a people or process problem.
-
Stage awareness
The stem places you before, during or after implementation, and the correct action belongs to that phase of the project.
-
People before configuration
Users resist or ignore the system, and you pick training, communication, sponsorship or feedback over another technical change.
-
Prioritize and scope
Many requests compete for a fixed timeline, and you rank them by business value, effort and dependency, or move items to a later release.
Three weeks after go-live, a sales director reports that half the reps still track deals in spreadsheets. A new validation rule or mandatory fields would not change behavior and may make it worse. The consultant should first check login and usage data, interview a few reps to find the friction, then combine targeted training, executive reinforcement and small usability changes such as simplified page layouts and a guided path.
Objectives 5
Official objectives from the Salesforce outline, in outline order.
2.1 Prior to an implementation, assess user experience, the communication plan, training, and change management, and establish metrics that measure success.Preparation work that sets the project up for adoption.
- What it means
- Before configuration starts, the consultant looks at how users will experience the system, how changes will be communicated, how people will be trained and how resistance will be managed. Success metrics are agreed up front so the project can be judged objectively.
- What to understand
- Identify the executive sponsor and change champions, map user personas and their daily tasks, and design page layouts, Lightning apps and mobile access around those tasks. Plan communications by audience and timing. Choose training formats such as role-based sessions, Trailhead, In-App Guidance and quick reference guides. Define measurable success criteria like login rate, opportunity update frequency, forecast submission rate or lead response time, with a baseline taken before go-live.
- How it shows up
- A project is about to start, and you pick the preparation step or success metric that is missing.
- Common confusion
- Defining success only as go-live on schedule instead of business and adoption metrics with a baseline.
2.2 During an implementation, outline and apply appropriate deployment considerations.Environments, release approach and deployment tools.
- What it means
- During build and release, the consultant decides which sandboxes to use, how changes move between environments, whether to launch all at once or in phases, and how data and users are prepared for cutover.
- What to understand
- Developer and Developer Pro sandboxes suit build work, Partial Copy suits testing with sample data, and Full sandboxes suit performance testing, staging and user acceptance testing with realistic volume. Change sets, DevOps Center, the Salesforce CLI and unlocked packages move metadata. Phased rollouts by region or team lower risk for large organizations, while a single cutover can suit small teams. Plan data migration order, user provisioning, permission assignment, a freeze window and a rollback approach.
- How it shows up
- A deployment scenario names environment needs, risk tolerance or team size, and you choose the sandbox or release approach.
- Common confusion
- Running user acceptance testing in a Developer sandbox that lacks representative data.
2.3 Post implementation, determine how to respond to low adoption, changing business requirements, and user access, and plan for continuous improvement.Sustaining and improving the solution after go-live.
- What it means
- Once live, the consultant monitors usage, fixes friction, handles new requests through governance and keeps access aligned with roles. Continuous improvement means regular releases driven by feedback and metrics rather than one large rebuild.
- What to understand
- Diagnose low adoption with login history, adoption dashboards and user feedback before prescribing a fix. Remedies include refresher training, in-app prompts, simplified layouts, manager use of dashboards in meetings and removing duplicate spreadsheets. New business requirements go through intake and prioritization, often via a Center of Excellence or steering committee. User access changes should use permission sets and permission set groups rather than new profiles.
- How it shows up
- Usage drops or requests pile up after launch, and you pick the diagnostic or governance step that comes first.
- Common confusion
- Adding required fields to force data entry, which tends to lower adoption and data quality.
2.4 Leverage the project management lifecycle to deliver a successful solution on time and within scope.Planning, controlling scope and managing risk across the project.
- What it means
- The project management lifecycle runs through initiation, planning, execution, monitoring and closing. A consultant uses it to set scope, schedule, roles and communication, and to handle risks and change requests as the project moves forward.
- What to understand
- Know the difference between waterfall and agile delivery, and when each fits. A RACI clarifies who decides and who is informed. A change control process evaluates new requests against timeline and budget before accepting them. Risk and issue logs track blockers, and regular status reporting keeps sponsors aligned. When scope grows, the right move is usually to re-prioritize or defer to a later phase with sponsor agreement, not to absorb the work silently.
- How it shows up
- A project faces scope creep, a missed milestone or unclear ownership, and you choose the project management response.
- Common confusion
- Accepting every new stakeholder request to keep people happy, which pushes the timeline and budget.
2.5 Conduct discovery workshops, analyze business requirements, define solutions, and prioritize use cases.Gathering and ranking requirements with stakeholders.
- What it means
- Discovery is where the consultant learns the current process, pain points and goals. Workshops, interviews, process mapping and review of existing reports and spreadsheets produce requirements that become user stories, and those are ranked by value and effort.
- What to understand
- Bring the right participants: decision makers, process owners and frontline users. Document current-state and future-state processes, then write user stories with acceptance criteria. Separate needs from wants using techniques such as MoSCoW. Prioritize use cases by business value, effort, risk and dependency, and confirm the ranking with the sponsor. Define the solution at a level that shows standard features first and flags gaps that need custom work or other products.
- How it shows up
- Stakeholders disagree or requirements are vague, and you pick the discovery technique or prioritization method.
- Common confusion
- Starting configuration from a feature wish list before the current process and pain points are understood.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Executive sponsor
Senior leader who owns the project's outcome.
- Remember
- Sponsorship drives adoption and resolves priority conflicts.
- Tested as
- Stalled decisions and low usage.
- Trap
- Expecting the consultant to settle business priorities.
-
Change champions
Respected users who promote and support the new system.
- Remember
- Recruit them early from each team.
- Tested as
- Adoption planning questions.
- Trap
- Relying on email announcements alone.
-
Success metrics with baseline
Measured KPIs compared before and after go-live.
- Remember
- Agree them before build starts.
- Tested as
- Pre-implementation questions.
- Trap
- Measuring only project deadlines.
-
Full sandbox
Complete copy of production metadata and data.
- Remember
- Best for staging, performance and UAT.
- Tested as
- Testing environment choices.
- Trap
- Using it for daily development.
-
Partial Copy sandbox
Metadata plus a sample of data from a template.
- Remember
- Suitable for QA and training.
- Tested as
- Testing with realistic sample records.
- Trap
- Expecting full data volume.
-
Phased rollout
Releasing to groups or regions in stages.
- Remember
- Reduces risk and allows learning between waves.
- Tested as
- Large or global implementations.
- Trap
- Choosing big bang for a complex global launch.
-
User story
Requirement written from the user's view with acceptance criteria.
- Remember
- As a role, I want, so that.
- Tested as
- Requirements analysis questions.
- Trap
- Writing stories as configuration tasks.
-
MoSCoW
Must, Should, Could, Won't prioritization.
- Remember
- Separates essential scope from nice-to-have.
- Tested as
- Scope and prioritization scenarios.
- Trap
- Treating every request as a must.
-
Change control
Formal evaluation of new requests against scope, time and cost.
- Remember
- Sponsor approves trade-offs.
- Tested as
- Scope creep scenarios.
- Trap
- Absorbing requests without review.
-
Adoption dashboard
Reports on logins, record updates and feature usage.
- Remember
- Diagnose before fixing.
- Tested as
- Post go-live usage questions.
- Trap
- Assuming the cause of low adoption.
-
Center of Excellence
Governance group that owns standards, intake and release cadence.
- Remember
- Keeps continuous improvement organized.
- Tested as
- Post-launch request handling.
- Trap
- Letting each team change the org directly.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Sandbox types
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Developer | Metadata only, small storage. | Individual build and unit testing. | Using it for UAT. |
| Developer Pro | Metadata only, larger storage. | Larger dev and integration testing. | Expecting production data. |
| Partial Copy | Metadata plus sampled data. | QA and training with realistic records. | Assuming full volumes. |
| Full | Full copy of metadata and data. | Staging, performance testing and UAT. | Refreshing it frequently; refresh intervals are long. |
Delivery approaches
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Waterfall | Sequential phases with fixed scope. | Detailed upfront requirements. | Choosing it when requirements are expected to change. |
| Agile | Iterative sprints with a ranked backlog. | Frequent feedback and reprioritization. | Skipping documentation and acceptance criteria. |
| Phased rollout | Releasing by team, region or feature set. | Lower risk per release. | Confusing a release strategy with a delivery method. |
Project phase actions
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Before build | Discovery, success metrics, change and training plans. | Sets direction and baseline. | Starting configuration first. |
| During build | Sandboxes, testing, deployment and cutover. | Controls release risk. | Testing without representative data. |
| After go-live | Adoption monitoring, governance, iteration. | Sustains value. | Treating go-live as the end. |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Force compliance
- What candidates pick
- Make more fields required so reps must enter data.
- Why it looks right
- It appears to guarantee data entry.
- Why it's wrong
- Mandatory fields add friction and often produce junk values; adoption problems need diagnosis, training and simpler screens.
Clue to watch for Users avoid the system after go-live.
-
Configure from the wish list
- What candidates pick
- Start building the features stakeholders listed in the kickoff email.
- Why it looks right
- It shows quick progress.
- Why it's wrong
- Without understanding current processes and pain points, the build may solve the wrong problem and require rework.
Clue to watch for Requirements are vague or conflicting.
-
Developer sandbox for UAT
- What candidates pick
- Run user acceptance testing in a Developer sandbox.
- Why it looks right
- It is cheap and quick to refresh.
- Why it's wrong
- It holds no production data, so testers cannot validate real scenarios or volumes; Partial Copy or Full sandboxes fit better.
Clue to watch for Business users need to test with realistic data.
-
Absorb scope
- What candidates pick
- Add the new request to the current release to keep the sponsor happy.
- Why it looks right
- It avoids conflict.
- Why it's wrong
- Unreviewed scope growth puts the timeline and budget at risk; change control lets the sponsor trade scope against time.
Clue to watch for A late request arrives near a fixed go-live date.
-
New profile per request
- What candidates pick
- Create a new profile for a team that needs extra access.
- Why it looks right
- Profiles are familiar.
- Why it's wrong
- Permission sets and permission set groups add access without multiplying profiles and are easier to govern.
Clue to watch for Access needs change after launch.
-
Big bang globally
- What candidates pick
- Launch to every region on the same day.
- Why it looks right
- One cutover seems simpler.
- Why it's wrong
- A phased rollout lets the team fix issues found in early waves before larger groups go live.
Clue to watch for Many regions with different processes and languages.
Answer framework
Use these steps for any scenario that asks what the consultant should do next on a project.
- Identify the project phase described in the stem: discovery, preparation, build, deployment or post go-live operation.
- Decide whether the underlying problem is about people, process or technology, because many stems disguise an adoption or alignment issue as a system problem.
- Check who must be involved, such as the executive sponsor, process owners, change champions or end users, before any decision is made.
- Choose the action that belongs to that phase, such as workshops and user stories, sandbox and release planning, or adoption diagnosis with dashboards.
- Tie the action back to agreed success metrics and scope, using change control or reprioritization when the request threatens the timeline.
Practice question
Want more like this? The Sales-Con-201 practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this section the largest share of study time, about thirteen to fifteen hours, because it carries a quarter of the exam. Read the Trailhead modules on change management, user adoption, Salesforce environments and application lifecycle management, then summarize each objective as a short list of before, during and after actions.
Practice with scenario writing. Take a fictional company, run a mock discovery with yourself as the consultant, and draft five user stories with acceptance criteria, a MoSCoW ranking, a communication plan and three success metrics with baselines. Then sketch a sandbox strategy and decide whether the rollout should be phased.
When answering practice questions, underline the time words in the stem, such as kickoff, during testing or two months after go-live. Eliminate any answer that belongs to a different phase. Next, eliminate technical fixes when the stem describes reluctance, confusion or misalignment. Keep a log of the consulting principles behind each miss, because the same principles repeat across many differently worded questions.
FAQ
How much of the Agentforce Sales Consultant exam covers Consulting and Implementation Strategies?
Consulting and Implementation Strategies is 25% of the exam, the largest section, which suggests about fifteen of the 60 scored questions as a planning estimate.
Do I need project management certification for this section?
No. You need practical knowledge of project phases, scope control, risk tracking, RACI charts and agile versus waterfall delivery as they apply to Salesforce projects.
Which deployment tools should I know?
Know change sets, DevOps Center, the Salesforce CLI and the sandbox types, along with when each fits. Detailed command syntax is not tested.
How are adoption questions usually framed?
They describe low usage or workarounds after launch and ask for the best response. Diagnose with data and feedback first, then choose training, sponsorship or usability improvements.
Is the discovery objective new?
Discovery and use case prioritization appeared in earlier versions as Consulting Practices. The current guide merges consulting and implementation topics into this single section.
What counts as a good success metric?
A good metric is measurable, tied to a business goal and has a baseline, such as lead response time, forecast submission rate or percentage of opportunities updated weekly.
Other CRM & Business Applications certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- HubSpot Inbound Marketing Certification Study guide
- Salesforce Certified Platform Developer I Study guide
- Google Ads Search Certification Study guide
- ServiceNow Certified System Administrator Study guide
- Salesforce Certified Platform Administrator Study guide
- ServiceNow Certified Application Developer Study guide
Test your Domain 2 knowledge
You have covered preparation, deployment, post-launch adoption, project management and discovery. Test yourself on scenarios that hinge on project phase and stakeholder judgment.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Sales-Con-201 AI tutor Get any concept explained your way