Sandbox tenants and rehearsing change
Configuration changes in a PLM are hard to reverse and their consequences are structural. A sandbox is not a demo environment — it is where you find out what a change does before it happens to everybody.
What a sandbox tenant is
A separate tenant with the same code, the same feature set and the same isolation guarantees as production. Not a reduced environment and not a shared demonstration instance — the same product, with your configuration and a copy of your data.
It refreshes from production on request, which is the property that makes it useful. A sandbox seeded once with sample data answers questions about the software; a sandbox holding a recent copy of your own structures answers questions about your data, and those are the questions that actually cause incidents.
Refreshes can be scoped. A full copy is the common case, but a refresh limited to one product line is faster and frequently sufficient, and it keeps the sandbox small enough that people are willing to break it.
What people rehearse in it
Three kinds of change account for nearly all sandbox use, and each is genuinely hard to reason about without running it.
- Configuration changes — a new rule, an altered workflow, a changed classification template. The question is never whether the configuration is valid; it is how much existing data it makes non-compliant. A gate condition that seems obviously correct can render four hundred released items unable to revise.
- Mass changes — a bulk edit across thousands of objects, run first in the sandbox to see the real count of affected structures and the real set of validation failures rather than the estimate.
- Integration changes — a connector mapping change, a new field, an altered publication scope. This is the highest-value case by some distance, because integration mistakes reach a system that is not yours and cannot be undone from here.
The failure it prevents
An administrator adds a gate condition: a revision cannot release without a linked specification. It is a good rule, agreed by everybody, and it takes about two minutes to configure.
The next morning, work stops across three programmes. Some four hundred released items have no linked specification because that practice began eighteen months ago and nothing retrospectively linked what came before. Every one of them is now unable to revise, and the rule cannot just be removed, because two programmes have already started relying on it.
The rule was correct and its blast radius was invisible. Applying it in a sandbox first produces the number — four hundred and eleven items, listed — which turns a two-minute configuration change into a two-week backfill plan followed by a two-minute configuration change.
How it meets the rest of the product
Configuration promotes from sandbox to production as a reviewable diff rather than by being re-entered by hand. Re-entry is where the discrepancies come from — somebody configures it twice, slightly differently, and the environments quietly stop matching.
Promotion is itself an audited change with an actor and a timestamp, which is what makes *when did this control come into effect* answerable. That question is asked at audits about controls, not about code, and a configuration change with no record is indistinguishable from one that was always there.
Agents can run in a sandbox, which is the responsible way to enable a new one or to test a custom agent's prompt. A finding rate discovered against a copy of real data is a real finding rate; one discovered against sample data tells you almost nothing.
Migration dry runs belong here too. An import of legacy structures is worth running against a sandbox first, where the failures are a list to work through rather than a partially loaded production tenant somebody has to unpick by hand afterwards.
How it meets your ERP
A sandbox connects to your ERP's test instance, never to production, and the configuration will not permit otherwise. A sandbox writing to a production ERP is the most expensive available mistake in this whole product, and it is prevented structurally rather than by a warning dialogue.
Where no ERP test instance exists — which is common in smaller deployments — the sandbox connector runs in a recording mode that captures what it would have published without sending it. That is less faithful than a real test instance and considerably better than nothing.
Publication rehearsal is the single most valuable thing a sandbox does. Seeing exactly which lines a structure would publish, which would fail validation and what the ERP would end up holding, before any of it happens, is the difference between an integration change and an integration incident.
Where the boundary is
A sandbox is not a backup. It is a copy taken at a moment for rehearsal, not a recovery point, and it is not retained or guaranteed as one. Backup and recovery are separate and run against production.
Sandbox data is real data and carries the same obligations. It is subject to the same access control, the same retention rules and the same tenant isolation, because a copy of production with relaxed permissions is a production data breach with an explanation attached.
Facts
| Fidelity | Same code, same features, same isolation as production |
| Seeded with | A refreshable copy of your data, not sample data |
| Refresh scope | Full, or limited to a product line |
| Rehearsed | Configuration changes · mass changes · integration changes |
| Highest value | Publication rehearsal — mistakes there reach a system that is not yours |
| ERP connection | Test instance only; production is structurally prevented |
| No test instance? | Recording mode captures what would have published |
| Not | A backup · a recovery point · a place with relaxed permissions |
Frequently asked
How is this different from a demo environment?
It runs the same code with your configuration and a refreshable copy of your data. A sandbox seeded with sample data answers questions about the software; one holding your own structures answers questions about your data, and those are what actually cause incidents.
What is the most common thing people rehearse?
Configuration changes, because the question is never whether the configuration is valid — it is how much existing data the change makes non-compliant. A gate condition that looks obviously correct can leave several hundred released items unable to revise at all.
Can we test integration changes safely?
That is the highest-value case. Publication rehearsal shows exactly which lines a structure would publish, which would fail validation and what your ERP would end up holding — before any of it happens, which is the difference between a change and an incident.
Could a sandbox write to our production ERP?
No. A sandbox connects to your ERP's test instance and the configuration will not permit otherwise. That is the most expensive available mistake in this product, so it is prevented structurally rather than by a warning dialogue somebody clicks through.
We have no ERP test instance. Is a sandbox still useful?
Yes. The connector runs in a recording mode that captures what it would have published without sending anything. That is less faithful than a real test instance and considerably better than discovering a mapping error in your production system instead.
How does configuration reach production?
As a reviewable diff that promotes, rather than by being re-entered by hand in production. Re-entry is where discrepancies come from — somebody configures it twice, slightly differently, and the two environments quietly stop matching in ways nobody notices for months.
Can we use a sandbox as a backup?
No. It is a copy taken at a moment for rehearsal rather than a recovery point, and it is neither retained nor guaranteed as one. Backup and recovery are a separate concern and run against production on their own schedule.