An environment is an isolated instance of Dataverse — its own database, its own set of security roles, its own customizations. Nothing you do in one environment affects another unless you deliberately move it there (usually via a solution, which we’ll cover in the Customization course). Every D365 CE tenant has at least one environment, and most real projects have several.

Environment types

  • Production — the live environment real users work in. Changes here affect real data and real business processes immediately.
  • Sandbox — a non-production copy used for development and testing. Can be reset, copied from production, or converted to production if needed.
  • Trial — a time-limited environment (typically 30 days) for evaluation or learning. Fine for following this course; not something you’d build real client work in.
  • Developer — a free, personal, non-expiring environment tied to one user’s account, intended for individual learning and prototyping (not team development).
The mistake almost every beginner makes. Building directly in production because “it’s just a quick customization.” Dataverse makes it easy to add a column or a business rule in two clicks, which makes it dangerously easy to do that in the wrong environment. Get in the habit of checking which environment you’re in — the environment name is shown in the top bar of the Power Platform admin center and, in most model-driven apps, in the page title — before you change anything.

How environments are managed

Environments are created, copied, backed up, and restored from the Power Platform admin center (admin.powerplatform.microsoft.com), not from inside any individual app. From there you can:

  • Create a new environment and choose its type, region, and whether it includes a Dataverse database
  • Copy a production environment into a sandbox (useful for testing with realistic data)
  • Back up and restore an environment to a specific point in time
  • Reset a sandbox environment back to an empty state
  • Manage security groups that control who can even see an environment

A typical project environment strategy

Most real implementations use at least three environments:

  1. Development — where customizations are actively built, broken, and rebuilt.
  2. Test/UAT — a stable sandbox where the client reviews and signs off on changes before they go live.
  3. Production — the live system. Changes arrive here only via a tested, exported solution — never built directly.

This is the same promotion pattern you’d expect from any software project, just applied to low-code configuration instead of only code.