Environment Setup

Environment model

All CRM implementations across DfE should follow this standard environment model. Using a consistent structure ensures developers and delivery teams can work in a familiar, predictable way across different projects without needing to relearn environment setups or adapt to varying processes. The recommended model uses four environments:

Environments model explaining Dev, Test, PreProd and Prod environments

Each environment should be aligned as closely as possible to avoid environment‑specific issues, with PreProd being a replica of Production where possible.

Development environment

Dev is the only environment where configuration changes, custom components, and development work are performed. All solution updates and customisation happen here before being packaged and deployed downstream.

Best Practice:

  • Unmanaged solutions are used in development
  • Access restricted to developers only
  • Keep Dev aligned with Test and PreProd settings so deployments behave consistently
  • Only sample test data should be stored in development

Test environment

Test is the first controlled environment beyond development and is used for functional testing, integration testing, and defect validation by test analysts within the project teams.

Best Practice:

  • Only managed solutions are deployed
  • Testers own this environment and manage test cycles
  • Developers have access for defect investigation but otherwise should avoid using the environment
  • Keep configuration aligned with PreProd and Prod for accurate testing results

PreProd environment

PreProd is the final staging environment and should operate as a near‑production replica. It is used for UAT, OAT, regression testing, release rehearsals, and final verification before go‑live.

Best Practice:

  • Only managed solutions are deployed
  • Treat PreProd with the same control and governance as Production
  • Any change requires a formal change request

Production environment

Prod is the live operational environment used by end users and must remain stable, secure, and tightly governed. Only approved changes should be deployed here through formal release processes.

Best Practice:

  • Only managed solutions are deployed
  • Generally, developers should not have admin access, standard user accounts only where required
  • Admin access limited to a small number of named individuals
  • Avoid using the service account to log in, restrict access to its credentials
  • Use named admin accounts where needed to ensure clear auditing and accountability

Consistency across environments

All environments should follow a consistent configuration pattern, including system settings, solutions, security and integrations. To maintain predictable behaviour and reduce deployment issues, Test, PreProd, and Prod must all use ALM pipelines for deployments. Using automated pipelines ensures that changes are deployed in a controlled, repeatable, and traceable way, and guarantees that the same deployment process is used across all environments.

Setting up a new environment

All Dynamics 365 environments must be created and managed through the Dynamics 365 Admin Centre. Within DfE, only users with the Dynamics 365 Administrator Azure role have the required permissions to provision environments. This role grants full administrative access to the Power Platform and Dynamics 365 Admin Centres, ensuring environments are created consistently and securely.

Currently, Eddie Haynes, Steve Tam, and David Oliver are the only users with this role.

To maintain control and inconsistent environment creation, all requests for new environments must be made through one of these three administrators. This includes requests for new Dev, Test, PreProd, Prod or temporary sandboxes needed for project work.