Practice before production: training people on software without a live sandbox

The access problem

Training for high-cost tasks runs into the same constraint everywhere: the person learning cannot safely practice in the live system, and giving them a realistic practice environment is expensive. Support agents need to close tickets, escalate issues, and apply refunds without reaching real customers. Operations staff need to approve invoices, assign permissions, and move deals through stages without touching real money or records. Admins configuring SSO, changing team roles, or provisioning databases cannot learn by experimenting in production.

These are not tasks people can learn by reading. The decision is inside the interface: which status, which priority, which approval action. A wrong choice in production reaches a customer, a ledger, or a permission before anyone notices. The learning has to happen before the first real action.

Why you cannot just use production

In some systems, new hires shadow an experienced colleague on a few real tasks, then start working supervised. This works when mistakes are immediately visible and reversible. It does not work when:

• A wrong action sends an email to a customer, posts a public reply, or triggers a notification someone else sees.
• The task changes money, inventory, a contract status, or another team's records.
• The error is silent: choosing Medium priority instead of High, or Pending instead of Solved, does not produce an error message, it just puts the work in the wrong place.
• Supervision is impractical because the experienced person cannot watch every click, or the task happens in a queue where speed matters.

These constraints describe most support, operations and admin work. Production is the wrong place to learn.

Why full sandboxes are hard to maintain

A sandbox tenant with realistic data solves the access problem. Learners can try every action, see every consequence, and reset the state when they are done. The cost is keeping it current. Every release that changes a screen, adds a required field, or moves a control means the sandbox teaches something subtly wrong unless someone updates it. Every realistic scenario needs test data: accounts, transactions, tickets, users. Someone has to create that data, and someone has to notice when the product evolves and the data no longer makes sense.

For large platforms with dedicated training teams and stable products, a maintained sandbox is worth the investment. For smaller teams, growing products, and training that covers dozens of different workflows, the maintenance cost is why training falls behind and people learn on the job instead.

What people do instead

When production is too risky and a sandbox is too expensive, teams reach for one of these:

Loom recordings and step-by-step documentation

A screen recording shows the task being done correctly. Documentation lists the steps and explains the decisions. Both are quick to make and easy to update. The limit is that watching or reading is not doing. A learner can finish a video, read a procedure, and still freeze when they meet the status dropdown in the live system, because recognising the correct choice is a different skill from making it under pressure.

Click-through demos built in authoring tools

Storyline, Captivate and similar tools let you rebuild the interface as slides with clickable hotspots. These can be made interactive, but the development cost is high: every screen is reconstructed, every control redrawn, and every product change requires re-authoring. Teams that already have eLearning developers and stable interfaces use this successfully. Teams without dedicated authoring resources find the effort does not scale to dozens of workflows.

Lightweight demo and onboarding tools

Tools that overlay tooltips and guided tours on the live product help with onboarding and feature discovery. They are excellent for showing where a control is. They are not designed for high-stakes decision practice, because the clicks happen in the real system. If the goal is to let someone practice choosing Reject without rejecting a real invoice, an in-app tour cannot provide that.

Each of these formats is right for something. The gap is hands-on practice for decisions, without rebuilding the interface and without a maintained sandbox.

What a recorded-screen simulation is good for

A recorded-screen simulation captures the task being performed once in the live product, then turns that recording into an interactive walkthrough. The learner sees the real screens and performs the real steps, but nothing reaches the live system. When they meet the decision step (the status dropdown, the approval action, the priority field), they make the choice, and a wrong choice produces feedback that explains why it is wrong in this situation and what the right answer is.

This is useful when:

• The workflow is stable enough to record. You do not need a finished product, but the task should be performable end to end. If the screens change every week, wait until the workflow settles.
• The decision is the hard part. Closed versus Solved, High versus Urgent, Approve versus Reject. The simulation finds out whether the learner knows the rule.
• There is no realistic sandbox, or maintaining one is impractical. One recording creates a reusable practice environment for that task. You update it when the product changes, not continuously.
• The task is performed often enough that fluency matters. If the task happens once a year, documentation is enough. If it happens daily, the person needs the habit.

This is not useful when:

• The learner needs to explore or experiment. A simulation follows one path through the task. If the training goal is "try different filters and see what happens", a sandbox is the right environment.
• The task involves integrations or real-time state. A recorded simulation shows the screens as they were. It cannot test whether an API call succeeds or a database query returns the right rows. Those scenarios need a live or sandboxed environment.
• The workflow has many conditional branches. One recording captures one path. If the task changes shape depending on what the learner finds, you would need a separate recording for each branch, which reduces the benefit.

A practical starter playbook

If you have one high-stakes admin, support or operations workflow where wrong actions have consequences and people currently learn by doing it supervised in production, here is a way to create hands-on practice without a sandbox.

1. Pick the task with the most expensive wrong action. Support: closing a ticket with the wrong status. Operations: approving an invoice that should be rejected. Admin: assigning a permission that grants too much access. Whatever people get wrong in production that reaches a customer, money or security.
2. Set up realistic scenario data in production or a temporary test tenant. A fictional customer, a realistic invoice, a representative ticket. It should look exactly like the real thing, because the learner will see these screens.
3. Record yourself performing the task correctly, once. Use Shadow Capture's browser extension or a similar tool that captures the screens and interactions. Do the task at the pace you would teach it: not rushed, not narrated, just the steps in order.
4. Author feedback for the decision step. The simulation will ask the learner to make the same choice you made. Write what they should read if they choose wrong: what that choice would do, why it is wrong here, and what the right choice is. Use the examples in writing feedback for wrong actions as a template.
5. Test it with someone who does not know the task. Watch them work through it. If they finish knowing what the decision means and can explain why their first wrong choice was wrong, the simulation is working.
6. Publish it as SCORM and add it to your LMS, or share it as a standalone file. Learners complete it before they touch the live system. The LMS records completion; the standalone file works immediately without infrastructure.
7. Update it when the product changes. A renamed button is a one-sentence edit. A redesigned screen is a second recording. See updating training after a release for the maintenance routine.

When you still need a sandbox

A recorded simulation is not a replacement for a sandbox when:

• The training covers integrations, API behaviour, or real-time data that cannot be captured in a static recording.
• The goal is experimentation: learners need to try different approaches, explore the product, or work through scenarios that branch in many directions.
• The product is an IDE, design tool, or other environment where the learner's creative work is the point, not following a procedure.
• Compliance or certification requirements specify hands-on work in a live environment, and a simulation does not meet that standard.

For those cases, invest in the sandbox. For the common case (teaching people to make the right decision in a known workflow without giving them production access), a recorded simulation gives you hands-on practice without the sandbox maintenance cost.

What Shadow Capture does, specifically

Shadow Capture is free during beta and makes this process fast:

• Record the task in your live product using the browser extension. One run-through, no editing.
• The authoring pass writes the scenario, steps, and feedback automatically. Review and edit the draft to match your team's policy.
• Export as SCORM 1.2, SCORM 2004, or standalone HTML. The walkthrough works in any LMS that supports SCORM, or on its own without infrastructure.
• Update it when the product changes. Edits for small changes, re-record for redesigned screens.

Current limitations during beta:

• SSO, team roles, and scored assessments are not ready yet.
• Each walkthrough follows one path. Conditional branching is not supported.
• The simulation works on the recorded screens; it does not interact with live APIs or databases.

These constraints suit the common case: one person needs to learn one high-stakes workflow, and the decision inside it is where the training pays. That is the access problem this solves.