Solutions

Unmanaged vs Managed Solutions

Understanding when to use unmanaged and managed solutions is essential for maintaining a consistent deployment process using Azure DevOps pipelines.

Unmanaged solutions

Unmanaged solutions are only used in the Development environment. They allow developers to create, modify and extend components while building new functionality.

Key principles for unmanaged solutions:

  • Used exclusively in Dev.
  • All configuration changes, custom components and extensions must be made within unmanaged solutions.
  • Unmanaged solutions must be checked into source control to allow the Dev environment to be rebuilt if needed.
  • No unmanaged customisations should ever be applied to Test, PreProd or Prod.
  • Developers must ensure that the unmanaged solutions remain the single source for all changes.

Managed solutions

Managed solutions are the only solution type permitted in Test, PreProd and Production environments.

Key principles for managed solutions:

  • Used in Test, PreProd and Prod environments.
  • Must be created from the Dev environment by exporting an unmanaged solution as managed.
  • Ensure controlled, repeatable deployments through Azure DevOps pipelines.
  • Prevent accidental modifications in higher environments, supporting strong governance and auditability.
  • All changes must flow through the pipeline as managed solution updates – no direct edits or unmanaged components are allowed in these environments.

Standard Solution Model

Dynamics 365 environments must follow a consistent solution structure across all stages of the ALM process. The structure varies slightly depending on whether the CRM hosts a single service or multiple services.

Single‑Service CRM Environments

If the CRM environment hosts only one service, follow the standard three‑solution model:

  • [Service name] Configuration
  • [Service name] Customisation
  • [Service name] Portal (if applicable)

An example would be the ICA CRM which only hosts the ICA service:

  • ICA Configuration
  • ICA Customisation
  • ICA Portal

This ensures a clean separation between service configuration, custom logic and portal components.

Solutions must follow this naming convention to ensure compatibility with our standard Azure DevOps pipeline model, which relies on consistent and predictable solution names.

Multi‑Service CRM Environments

If the CRM environment hosts multiple services, a shared core layer is required in addition to the service‑specific solutions. The solution structure should be:

  • [CRM name] Core
  • [Service name] Configuration
  • [Service name] Customisation
  • [Service name] Portal (if applicable)

An example would be the APM CRM which will host all application & programme related services, one of which is Breakfast Clubs:

  • APM Core
  • Breakfast Club Configuration
  • Breakfast Club Customisation
  • Breakfast Club Portal

In this scenario, use different publishers with a different prefix for the CRM and service specific solutions. For example, apm_ for the APM Core solution and bc_ for the Breakfast Club solutions.

Purpose of the CRM Core Solution

The [CRM name] Core solution contains components that are common across all services within the CRM. These are shared, generic components that must be developed independently of any specific service.

Core components include:

  • Core Apps
  • Shared Tables (i.e. Contacts, Cases)
  • Global Choices
  • Shared Security Roles
  • Reusable Web Resources

For example, Contacts and Cases are used by many DfE services and must always exist as generic, centrally‑owned components, not duplicated or modified differently per service.

Any service‑specific extensions or additional components must be added to the individual [Service name] solutions instead.

Solutions are layered in the order shown above. The [CRM name] Core solution forms the base layer, with each [Service name] solution layered on top. For example, the Contact table may include a generic form within the [CRM name] Core solution. If a specific service requires an additional field on the Contact table, that service‑specific field should be added within the corresponding [Service name] solution. When deployed, the [CRM name] Core solution is installed first, providing the shared components, followed by the [Service name] solutions, which apply the service‑specific extensions.

To avoid conflicts between two unmanaged solutions, you should also consider hosting the [CRM name] Core solution in a separate Development environment from the one used for the [Service name] solutions. This allows the [CRM name] Core solution to be developed and exported as a managed layer, which the service‑specific unmanaged solutions can then safely build upon in their own Dev environments. This approach would require two Dev environments.

Configuration Solution

The Configuration solution contains the core configuration items for each service.

It should include:

  • Apps
  • Choices
  • Dashboards
  • Email Templates
  • Security Roles
  • Sitemaps
  • Tables
  • Web Resources

Customisation Solution

The Customisation solution contains the service’s automation, logic and references.

It should include:

  • Power Automate Flows
  • Plugins
  • Classic Workflows (real‑time)
  • Environment Variables
  • Connection References

Portal Solution (If Applicable)

If the service uses a Power Pages site, all portal assets must be captured in a dedicated Portal solution.

It must include:

  • Site
  • Site Components
  • Site Languages
  • Environment Variables

Additional Guidance

For additional guidance or confirmation on the correct approach, please contact the CRM Architect or Lead Developer.