SfSkills Domains Docs GitHub

Home / admin / change-management-and-training

change-management-and-training

Use this skill when planning user adoption, structuring Salesforce training materials, drafting release communications, or running a change impact assessment for a Salesforce rollout or update.

Open the skill folder on GitHub

Change Management and Training

Use this skill when a Salesforce rollout, major feature release, or org-wide configuration change requires structured user adoption planning, role-based training, and stakeholder communications. This skill produces change impact assessments, training plans, and release communication artifacts — it does not implement the technical change itself.

Before Starting

Gather this context before working on anything in this domain:

Questions to Ask Before Configuring

Ask these before writing a single message or booking a room. Each one traces to a failure documented in references/gotchas.md, and each answer becomes a field in the plan artefact in references/worked-examples.md.

AskWhy it mattersWhat a good answer adds
"Which permission set carries the new access, who assigns it, and on what day relative to the announcement?"PermissionSetAssignment records are data created per user, not part of the metadata deploy — a message that names a field before assignment produces a ticket wave (gotcha 7)The assignment step placed on the comms timeline with an owner, and the count query that verifies it
"Which page will each persona actually see — which app, record type, profile and form factor?"A Lightning page assignment is keyed on all four, so the admin's screenshot may be a different page from the reps' (gotcha 8)The screenshot matrix, and an explicit "nothing changes for you" message for personas whose record type keeps the old page
"Which org will training run in, and when is it refreshed relative to the deploy?"A sandbox refreshed before the deploy teaches the configuration users are about to lose, and the refresh interval makes the mistake expensive to undo (gotcha 5)A sequenced refresh date on the persona's training environment row
"Does the go-live window cross this instance's seasonal upgrade date?"The UI, click paths and prompt anchor points can move mid-rollout (gotcha 9)A recorded upgrade-date check and, if needed, a rollout split either side of the weekend
"What behaviour — not what login — tells us this landed?"LoginHistory measures presence; only record counts and PromptAction measure behaviour, and list-view usage is not queryable at all (gotcha 3)Adoption metrics written as SOQL or report definitions, with the pre-go-live baseline captured
"Who is affected who never opens a Lightning page?"Integration and API-only users are broken by the same field change and reached by none of the channels (gotcha 10)An integration-user persona row, a mapping request instead of an announcement, and an id-based exclusion from the metrics
"Who owns each message, and who signs it?"An unowned row is an unsent message; a message signed by IT about a sales process change is ignoredA named owner per row, which the checker enforces

What a proper change plan adds over just sending an announcement: the people who are told, the people who are trained, the people who get access, and the people who are measured are provably the same set — and where they differ, the difference is recorded rather than discovered at go-live.

Core Concepts

Change Impact Assessment

A change impact assessment maps each Salesforce change to the user roles it affects, the current versus future state workflow, and the severity of disruption. Salesforce projects fail adoption when the impact is assessed too late — typically after development is complete and training is an afterthought.

Run the assessment during requirements gathering, not after UAT. The output is a matrix:

ChangeAffected RolesCurrent BehaviorNew BehaviorTraining RequiredCommunication Priority
New Opportunity stageSales Rep, Sales Manager6 stages8 stagesYes — field meaningsHigh
Page layout updateService AgentFields scatteredGrouped by taskYes — guided walkthroughMedium
New validation ruleAll users on AccountNoneRequired fieldsNo — error message explainsLow

User Adoption Planning

Salesforce defines adoption across three dimensions: breadth (are people logging in?), depth (are they using the features?), and quality (is the data clean and complete?). Each requires different interventions.

Six Levers of Change (Salesforce official framework): Salesforce training explicitly teaches that communications and technical training alone are insufficient for sustained adoption. Six levers must be addressed simultaneously: Leadership (executives visibly use and champion the system), Ecosystem (peer pressure and social norms reinforce usage), Values (the change connects to what users personally care about), Enablement (users have the skills and tools to change their behavior), Rewards (incentives align with the new behavior, not the old), and Structure (the new way is easier than the old way by design). Assess which levers are missing when adoption is lagging.

Adoption levers available natively in Salesforce:

LeverDescription
In-App Guidance (Walkthroughs)Step-by-step prompts shown inside the Salesforce UI, configurable without code. Navigate to Setup > In-App Guidance. Target specific pages and user profiles. Use for new features and process changes.
PathVisual stage guidance on records (Opportunity, Lead, Case). Shows key fields and coaching text per stage. Configured per object and record type in Setup > Path Settings.
ChatterAnnouncements, group updates, polls to surface process changes inside the platform users already use.
Adoption DashboardsThe Salesforce Adoption Dashboards package (available on AppExchange, free from Salesforce Labs) provides prebuilt reports on login frequency, record creation, and feature usage by profile.

Role-Based Training Structure

Training fails when it is delivered as a generic platform tour. Effective Salesforce training is structured by role and anchored to the tasks that role performs daily.

Recommended structure per role:

  1. Why it changed — 2-3 sentences on the business reason (not the technical reason)
  2. What is different — before/after comparison of the specific screens or steps they use
  3. Hands-on exercise — sandbox or training org walkthrough of their specific scenario
  4. Where to get help — in-app guidance, Chatter group, help contact

Salesforce Trailhead provides free, official, role-specific learning trails. Use Trailhead Academy trails for common roles rather than building content from scratch for standard platform features.

Release Communication Templates

Release communication for Salesforce projects follows a different cadence than typical IT releases because many users are non-technical. Announcements must be in business language, role-specific, and tied to a concrete go-live date.

Standard release communication pack:

  1. Executive Summary (1 paragraph) — what changes, why, and when
  2. Role-Specific What Changed Guide — per affected role, bullet-point list of what is different
  3. Go-Live Announcement — email/Chatter post sent day-of, links to training, names the support contact
  4. Post-Go-Live Check-In — 2-week follow-up asking for feedback, surfacing top issues

Common Patterns

Pattern: Phased Rollout with Pilot Group

When to use: The org has more than 50 affected users or the change significantly alters an existing workflow. Piloting with 5–10 volunteer power users before full rollout reduces go-live risk and generates real testimonials for the broader communication.

How it works:

  1. Identify 5–10 pilot users (mix of skeptics and enthusiasts, covering each affected role)
  2. Run pilot group through training 2 weeks before go-live
  3. Gather feedback on training clarity, gotchas, and missing guidance
  4. Update training materials and in-app guidance based on pilot feedback
  5. Send go-live announcement to full audience referencing pilot feedback: "Our early users loved X"

Why not skip the pilot: A full rollout with broken training materials creates a support spike, erodes trust, and is much harder to recover from than a delayed launch.

Pattern: Adoption Metrics Dashboard

When to use: Any rollout where leadership wants to track adoption progress post-go-live.

How it works:

  1. Install Salesforce Adoption Dashboards from AppExchange (Salesforce Labs, free)
  2. Configure report filters by profile to segment by role
  3. Define adoption targets per role (e.g., 90% of Sales Reps logging in daily within 4 weeks of go-live)
  4. Schedule weekly adoption review meeting for the first 4 weeks post go-live
  5. Use Chatter groups or manager escalation for roles below target

Why not use ad hoc reports: The Adoption Dashboards package provides prebuilt metrics that Salesforce has validated. Building from scratch takes time and often misses important signals like feature engagement vs. login frequency.

Pattern: In-App Guidance for Process Changes

When to use: A page layout, required field, or workflow step is being added or changed. Users need just-in-time guidance without attending a training session.

How it works:

  1. Navigate to Setup > In-App Guidance
  2. Click "Add" and choose the target Lightning page and prompt type (floating, docked, or walkthrough)
  3. Set profile/permission set filters to show the prompt only to affected users
  4. Write prompt copy in plain language referencing the business task, not the field name
  5. Deactivate the prompt 60 days after go-live (when users are habituated)

Decision Guidance

SituationRecommended ApproachReason
< 20 users affected, minor UI changeIn-App Guidance prompt onlyOverhead of formal training exceeds impact
20–100 users, new workflowRole-specific What Changed Guide + 30-min live sessionEnough scale for structured training, small enough for live delivery
> 100 users or critical processFull change pack: impact assessment, pilot, role training, adoption dashboardLarge audience and high complexity justify full change management
Executive stakeholders need visibilityAdoption metrics dashboard scheduled reportLeadership needs numbers, not anecdote
Users reverting to old tools (spreadsheets, email)Escalation via manager + targeted in-app guidanceResistance requires reinforcement, not re-training
Trailhead trail exists for the featureAssign trail via myTrailhead or direct link in communicationsDo not rebuild what Salesforce already provides for free
  1. Build the ship list, then the persona list. Name every metadata piece that deploys and the skill that owns it (references/worked-examples.md §1), then derive personas from who touches the object, not from who attends meetings — that is what catches the unaffected record type and the integration user.
  2. Assess impact in three columns per persona: what changes on screen, what changes in process, what permission changes ship. A persona with no entry in any column is a persona who needs a "nothing changes for you" message, not silence (references/worked-examples.md §2).
  3. Fill the plan artefact. Copy the YAML from references/worked-examples.md §3 to <project>/change-plan.yaml and fill it in: every message gets an audience, channel, D±n timing and owner; every persona gets a training format (none is a legal, recorded answer) and a training environment.
  4. Sequence the training environment against the deploy. Deploy to the training sandbox → validate → run labs → deploy to production → refresh the training org. Confirm the seasonal upgrade date with admin/salesforce-release-preparation and the refresh window with devops/sandbox-refresh-and-templates before committing dates.
  5. Write every adoption metric as a query. LoginHistory for presence, PromptAction for guidance engagement, record counts for behaviour (references/worked-examples.md §6). Capture the baseline before the deploy. If a metric has no query — list-view usage, for instance — drop it at planning time and say why.
  6. Lint the plan. python3 scripts/check_change_management_and_training.py --file <project>/change-plan.yaml --repo-root . — it fails on a missing owner, a calendar date where a D±n offset belongs, an audience that matches no persona, a duplicate id, an adoption metric with no query, or a reads: path that does not resolve.
  7. Walk references/gotchas.md against the finished plan before the first message goes out. Most of the ten failures are cheap to fix a week early and expensive to fix on go-live morning.

Review Checklist

Run through these before marking the change management deliverable complete:

Salesforce-Specific Gotchas

  1. Profile targeting on a prompt is the wrong lever — target the audience with userAccess = SpecificPermissions or a uiFormulaRule custom-permission criterion, so one permission-set assignment opens the field and the guidance together.
  2. A Path is bound to one record type — the Metadata API allows only one path per record type per object; a new record type starts with no coaching text and inherits none.
  3. Login counts are not adoption — LoginHistory includes OAuth and integration logins, and in an SSO org the human browser login is a SAML value, so the copied LoginType = 'Application' filter hides the very users you are measuring.
  4. The permission set deploys; the assignment does not — PermissionSetAssignment records are created per user, so any message naming a new field must land after the assignment runs.
  5. The page you screenshotted may not be the page they see — the assignment is keyed on app, record type, profile and form factor.
  6. The training sandbox must carry the change — a refresh timed before the deploy teaches the configuration users are about to lose.

All ten, with the source for each, are in references/gotchas.md.

Output Artifacts

ArtifactDescription
Change Impact Assessment MatrixTable mapping each change to affected roles, before/after behavior, training severity, and communication priority
Adoption PlanDocument covering success metrics, training delivery plan, adoption levers, and milestone dates
Role-Based What Changed GuidePer-role bullet list of what is different; written in business language, not technical terms
Go-Live Announcement TemplateEmail/Chatter post template announcing the change, training resources, and support contact
Post-Go-Live Check-In Template2-week follow-up communication template requesting feedback and surfacing help resources
change-plan.yamlThe lintable artefact holding personas, communications, adoption metrics and the feedback loop

Reference Files

FileRead it when
references/worked-examples.mdYou need the filled-in artefact: impact table, plan YAML, training plan, in-app guidance decisions, adoption queries, feedback loop
references/examples.mdYou want two contrasting rollout narratives (200-agent Service Cloud go-live; a required-field change) and the go-live-day-training anti-pattern
references/gotchas.mdBefore the first message goes out, and whenever a plan looks finished — ten platform behaviours that break rollouts
references/llm-anti-patterns.mdReviewing AI-generated change-management output, or self-checking your own
references/well-architected.mdJustifying the approach to an architect or sponsor; also holds the source list
templates/change-management-and-training-template.mdStarting a plan from scratch — the blank form of the worked example
scripts/check_change_management_and_training.pyLinting a finished change-plan.yaml

Package files