What are Dataverse environments and how many do I need?
By Emil Björk · Microsoft business apps consultant, Gothenburg
An environment is an isolated Dataverse database plus the security, apps, and flows around it. The standard split is three: Development (unmanaged solutions, iteration), Test/UAT (managed solutions from Dev, business testing), Production (managed solutions from Test, end users). Larger programmes add a per-developer sandbox and a dedicated release environment; nobody serious ships from a single environment.
Environments are the unit of ALM in Dataverse. Unmanaged solutions live in Dev; every downstream environment receives managed solutions moved through a pipeline (GitHub Actions, Azure DevOps, or Power Platform Pipelines). Skipping the split and editing Production directly is the single most common cause of unrecoverable damage in this stack — there is no reliable 'undo' once you have.
For very small teams a two-environment setup (Dev → Prod) is defensible if the release cadence is slow and users tolerate the occasional Dev-caused outage. Every organisation past a handful of makers should run three.
Go deeper
- Environment strategy for Dynamics 365 projectsHow to design dev / test / UAT / production environment topology for a Dynamics 365 implementation — naming conventions, refresh cadence, data isolation.
- Solution import / export pipelines for DataverseHow to automate Dataverse solution promotion through dev / test / prod — Power Platform CLI, Build Tools, GitHub Actions, and Power Platform Pipelines.
- ALM with GitHub Actions for Power PlatformHow to run Power Platform CI/CD with GitHub Actions — Microsoft's official workflows, source structure, and the differences from Azure DevOps.