A working method for the situation most trainers are actually in: the training environment costs too much, is not built yet, cannot be provisioned for 200 people, or holds real data nobody should be practising in.
You can build effective software training without a sandbox by separating two things that usually get bundled: learning a procedure and exploring a system. Most of what an ordinary user needs is procedural, the sequence of screens, the fields that matter, the one place everybody gets it wrong. That can be taught in a guided walkthrough captured from a real interface, where the learner clicks through the actual screens in the actual order, with no credentials, no provisioned tenant and no reset between cohorts.
What a walkthrough cannot do is let someone break something and see what happens. Troubleshooting, exploration, and any skill where the learner must watch the system react to input they invented still need a live system.
So treat it as triage, not as a substitute. Get the many people who need competence through walkthroughs, and spend scarce environment time on the few who need to experiment. The rest of this article is the method.
Do this before you record anything.
Go through the task list and ask one question of each item: does the learner need the system to respond to a decision they made, or do they need to know the sequence? If it is the sequence, a walkthrough is sufficient and often better, because it removes the environment as a source of failure. If they have to react to an outcome they could not predict, they need the real thing.
Expect the split to surprise you. On most rollouts the majority of named tasks turn out to be procedural, and environment demand collapses to a handful of roles. Write that result down. It is also the argument you take to whoever owns the budget.
You need the system once, for one person, rather than for everyone at once.
That is the leverage in the whole approach. Provisioning 200 accounts is a project; getting one competent person into a test tenant for an afternoon is a request. Capture once, and the recording serves every cohort with no reset, no seat cost and no scheduling.
Whatever is on screen is captured. That is the rule to plan around. A capture is a faithful copy of what was displayed, customer names, account numbers, salaries, patient identifiers. Blurring in post is slow and easy to get wrong on the one screen nobody checked.
So do not capture from production with a live account. Use a test or QA tenant seeded with obviously fictional records; if you must record in a real environment, create fictional records first and work only with those.
Checks before you press record: sign in as the training user, not yourself; close other tabs and notifications; hide anything docked in the interface that shows real names, recent items, activity feeds, search history; and check the address bar and page title, which often carry a record identifier.
Go through the finished walkthrough screen by screen as a reviewer, not as its author, authors skim screens they have already seen forty times. If the system holds anything regulated, get someone from the data-owning team to do a pass.
The difference between a walkthrough that works and a video is the sequencing.
A recorded video makes the learner a spectator, and attention drops accordingly. A guided walkthrough can make them act, but only if you build it that way. Every screen should end with something the learner has to do, and that should be the thing they will do at their desk.
If a screen requires four actions, it is four steps. The learner should always know exactly what the next click is, and get feedback the moment they make it.
Point at the actual button in the actual place, so the learner's hand goes to the coordinate it will go to in the live system. Do not paraphrase the interface, use it.
Where a step needs a paragraph of context, give it its own step with no click target. Mixing "read this" and "click that" on one screen means one gets ignored, and it is always the reading.
Ten to fifteen steps is a good ceiling. Past that, completion falls and the learner cannot find their way back to the part they needed. Split a long procedure at a natural boundary, where the record moves to someone else, say.
"Click Submit" teaches nothing the arrow pointing at Submit had not already taught. The words on a step are the only place to put knowledge that is not visible on screen, so spend them there. An instruction that earns its space usually contains three things: the action, the reason, and the consequence of getting it wrong. "Set the cost centre to the requester's, not yours. This drives the approval routing, put your own in and it goes to your manager, who will reject it." That is the difference between a procedure someone follows and a procedure someone understands.
Two habits: name the field exactly as the interface names it, so the learner can match text to screen; and put the exception where the exception happens, because a caveat attached to its own screen gets read and the same caveat in a closing slide does not.
This is where most attempts at sandbox-free training collapse.
Real procedures branch. The approval path differs by amount; the form differs by region; the correction differs by whether the record has posted. The instinct is to build one comprehensive walkthrough handling every path, and it is the wrong instinct, the result is a maze that is hard to author, hard to maintain, and hard to follow, because the learner spends attention on navigation instead of the task.
Build one short walkthrough per path instead, with a plain index in front: Under £5,000, £5,000 and over, Capital request. Three focused walkthroughs of eight steps beat one of thirty with branch logic:
Reserve the genuine decision points, where the learner must choose a path rather than be told which one they are on, for the live environment session.
The interface will change. A quarterly release moves a button, a configuration project adds a mandatory field. Stale training is worse than none, because learners stop trusting it after the first mismatch.
Three things make this survivable. Keep the editable source project, not only the published output, where the next person will find it. Keep walkthroughs short and single-purpose, so a change touches one small asset. Get on the release notification list, so a change reaches you before it reaches a learner.
Then budget the re-capture as a recurring cost of the approach rather than a failure of it. Tooling that lets you re-record a single changed screen rather than the whole procedure reduces it materially, and is worth checking for when you evaluate anything.
A walkthrough is a guided reproduction of a system, not the system. It will not let a learner type a value nobody anticipated and watch the consequence, and it will not surface errors that only appear under real data volumes, permissions and integrations. It is a poor way to teach anyone whose job is to diagnose failures rather than execute a procedure. Nor is it evidence: if certification requires proof that someone completed a task in the real system, a completion record from a walkthrough is not that proof.
What it does is change the shape of the demand. Instead of 200 people needing an environment, the 30 who need to experiment get one, with more time each, and arriving already knowing where things are. Argued that way, "we cannot get a sandbox" often becomes "we can get a much smaller sandbox".
Related: interactive software training, software training simulation, ERP training software, and the rest of the library in resources.
Capture one real procedure from a test tenant and put it in front of a learner before you commit to a curriculum. Demo Maker Pro records the real screens and exports a walkthrough you can host yourself.
Start your free 7-day trial