A launch training plan gets decided before user acceptance testing (UAT), not in the week of go-live. Before the first test, it has to say who is trained and in what order, when, on which processes, in which environment and with which data. Leave it until later and it shrinks to a generic demo, given to everyone in the same week.
Take key users who see Salesforce for the first time on the first day of UAT. They spend their sessions looking for where a field is, and the defects they log are navigation questions. Nobody spots the real process gaps (a missing approval step, a status that matches nothing in your business), so they resurface in production. UAT gets signed off, but what it really tested was how people found their way around the tool.
What must be decided before UAT?
The plan comes down to a few decisions, but each one depends on someone else in the project. UAT dates come from the integrator’s schedule. Someone has to request the training sandbox, configure it and then load it. The data set goes through the team preparing the data migration. Key users have to be released by their managers, sometimes for whole days. None of this can be settled at the last minute.
The programme lead, internal or external, writes the plan with the integrator and the key users. The business sponsor signs it, because the sponsor is the one who gives the teams the time. Read the integrator’s contract too, to see whether it covers admin training and train-the-trainer, and who supplies the training materials.
Who should be trained first, and why in that order?
One rule is enough: train each group before the people it will have to help.
Admins come first. They take over the org when the integrator leaves. Until then, they prepare the training sandbox and answer questions during UAT. An admin who is seeing the configuration for the first time alongside the users helps no one. An admin who is new to administration needs a different course from one who already runs an org: see ADX201 or ADX211.
Key users come next. They are people from the business, one per team or per process, who run UAT and then provide first-line support. If they are trained before UAT, they test their process from day one. They are also the best people to train the later waves: they speak their colleagues’ language and know the exceptions.
Managers come before their teams. Projects often get this order the wrong way round, and it is the order that decides adoption. A manager who still asks for the spreadsheet on Monday morning can undo their team’s training in a single meeting. Managers trained first learn to run their teams from reports and dashboards, and know which fields they will insist on. They can then free up their teams’ time. Their session is built for them, with less data entry and more reading and deciding.
End users come last, as close to go-live as possible. They are the largest group, and what they learn has to be useful the very next day.
When should you train, and what is each wave for?
Admins and key users are trained before UAT, on the configured org, with a clear aim: being able to run a process end to end and say whether it is right. UAT then becomes the time to write the training materials, because each approved scenario turns into an exercise with its starting data and its expected result.
Managers and end users wait for a stable configuration and are trained just before go-live. Training too early has two costs: people forget, and UAT fixes change the screens they learned. Training on the day itself has a different cost: nobody is available, and the first real question arrives before the session ends.
After go-live, training is there to correct. Short sessions cover the questions that keep coming back to support and go further into reports for managers. New joiners are trained in these sessions too. This work carries on after hypercare ends, as every release that changes a screen people use every day means updating the materials. Who decides on those changes is a matter for Salesforce governance, and the training plan needs its own line there.
What should you train on, where, and with which data?
Your processes are the material. A generic exercise (“create an account, then an opportunity”) means nothing to a sales rep who needs to know how your company qualifies a prospect, who approves a discount and when a quote goes out. So the exercises reuse the UAT scenarios, in the company’s vocabulary and with its required fields. The test is simple: the next day, can the person repeat on their own what they did in the session?
The environment is a training sandbox, kept apart from production and from the UAT sandbox. In production, an exercise creates real records that someone will have to clean up. In the UAT sandbox, exercise data gets mixed in with the test cases. The training sandbox gets the approved configuration, and each participant logs in with a user that has the profile of their role. A trainer logged in as an administrator sees buttons and fields the people in the room will not have.
I have seen this happen in training: my old demo org had features already switched on and showed different menus from the trainees’ orgs. Since October 2026, I rehearse every step of my materials before the session, in a new org set up the same way as theirs. The same rule applies to a launch: rehearse each exercise before the session, with a user that has the trained profile.
The data has to be realistic and anonymised. An empty sandbox is poor for training, because a report with no data shows nothing. A raw copy of production has the opposite problem: real customers’ contact details and histories, visible to the whole room. A good data set keeps the shape of real data (accounts with their contacts, opportunities and cases, plausible statuses) and replaces anything that identifies a person. Get the data protection officer (DPO) to approve the anonymisation method before the first session.
This data set is built with the team preparing the data migration, on the same objects and in the same load order. Once anonymised, the data from a load rehearsal can feed the training sandbox. For the migration method, see Salesforce data migration: what to prove before cutover.
The order of the exercises also matters. In an ADX201 session in September 2026, each exercise relied on the one before. By the time the session reached reports, some trainees did not have the object created the day before, and the import failed on the parent-child order. My materials, revised in October 2026, give each exercise its own starting point, a five-minute catch-up and a supplied data set.
How do you know whether the plan worked?
Attendance sheets and end-of-session evaluations measure the session itself. A session can be well rated and still produce users who go back to their spreadsheet the next day. The signals that help show up in the project and in the org.
- During UAT, defects are about the process (a rule or a permission), not about where a button is.
- On go-live day, users do their routine tasks without a trainer beside them, and key users absorb the first questions.
- In the following weeks, support gets fewer “how do I” questions, and key users handle the ones that remain.
- In meetings, managers run the business from their reports and dashboards, and the parallel spreadsheet disappears.
- In the data, required fields hold meaningful values, and records are created directly in Salesforce.
These signals are set before UAT, each with an owner and a date to read it after go-live. Without that, the review comes down to impressions. A signal that does not move points to the group or the process where a session needs to be rerun.