Glossary
Sandbox
By Emil Björk · Microsoft business apps consultant, Gothenburg
A non-production Power Platform or Dynamics 365 environment for development, testing, training, and demos — isolated from production data.
A sandbox environment in the Power Platform and Dynamics 365 is a non-production environment intended for development, testing, training, demos, and risk-free experimentation. Sandboxes are isolated from production — separate database, separate users where appropriate, separate integrations — so a mistake made while testing (a bad bulk update, a misconfigured workflow that fires on every record) never touches real customer or financial data. They can be copied from production (the most common pattern, giving testers realistic data and volume to work against) or reset to a clean state for a fresh start.
In practice, "isolated" needs a caveat that catches people out: sandboxes typically run on lower infrastructure priority than production, meaning they may pause during periods of inactivity, throttle under heavy use, or receive platform updates sooner than production does — useful for surfacing an update-related issue before it hits customers, but a real problem if anything business-critical is quietly running in a sandbox that then pauses or breaks unannounced. This is also why outbound integrations from a sandbox need deliberate handling — a sandbox copied from production inherits production's connection references and, unless reconfigured, can end up sending test transactions to a live external system (an email service, a payment gateway, a partner's API) that has no idea it's receiving test data.
Where confusion shows up: most Dynamics 365 SKUs include some number of sandboxes in the licence, which leads teams to assume sandbox capacity is unlimited — additional sandboxes beyond the included allotment are a paid add-on, and capacity planning for the environment topology (how many dev, UAT, training, and pre-production sandboxes a project actually needs) is a real cost conversation, not an afterthought. The healthy pattern is at least one dev, one UAT, and one training sandbox per major Dynamics 365 deployment, alongside one or more production environments — fewer than that and changes collide with each other; meaningfully more than that without a specific need just adds licensing cost and administrative overhead.
Related terms
Mentioned in these guides
- AL compiler errors in Business Central
- AL extension architecture
- The AL test framework
- ALM with GitHub Actions for Power Platform
- Backup strategy for Dynamics 365
- Bulk delete jobs in Dataverse
- The Business Central API and OData services
- The AL debugger in Business Central — a deep dive
- Business Central environments and sandboxes
- Business Central extension install and upgrade errors
- Business Central feature management
- Business Central job queue errors
- Multi-company setup in Business Central
- Business Central performance tuning
- Business Central posting setup errors
- RapidStart Services in Business Central
- Business Central release waves explained
- Business Central report layout errors
- Copilot in Business Central: what's actually shipped
- Copilot Studio for Dynamics 365
- Dataverse data import templates
- Environment variables in Dataverse — a deep dive
- Dataverse plug-ins explained
- Dataverse plug-in exceptions explained
And 25 more — this term shows up across the library.