Skip to content
Back to guides

Dataverse Solution Management Best Practices

A comprehensive guide to managing Dataverse solutions for Dynamics 365 CE projects, covering solution architecture, layering, and ALM strategies.

February 8, 202615 min

Why Solution Management Matters

Poor solution management is the number one cause of deployment failures in Dynamics 365 CE projects. A well-planned solution strategy prevents merge conflicts, simplifies deployments, and makes your environments maintainable long-term.

Solution Architecture

Segmented Solution Strategy

Never put everything in a single solution. Instead, segment by functional area:

| Solution | Contents | Example | |----------|----------|---------| | Core / Platform | Shared entities, global option sets, security roles | Contoso_Core | | Feature modules | Feature-specific entities, forms, views, flows | Contoso_Sales, Contoso_Service | | Integrations | Connection references, custom connectors, integration flows | Contoso_Integration_ERP | | UI / Presentation | Sitemap, app modules, dashboards | Contoso_App_Sales |

Layering Rules

  • Core is always deployed first and has no dependencies on feature modules
  • Feature modules can depend on Core but not on each other
  • Integration solutions depend on Core and relevant feature modules
  • UI solutions sit on top and reference everything below
┌─────────────────────────┐
│     UI / Presentation    │
├─────────────────────────┤
│      Integrations        │
├──────────┬──────────────┤
│  Sales   │   Service    │  ← Feature Modules
├──────────┴──────────────┤
│     Core / Platform      │
└─────────────────────────┘

Publisher and Prefix

Set these up correctly from day one — they cannot be changed later:

  • Publisher name: Use your organization name (e.g., Contoso)
  • Prefix: Short, unique, 3-5 characters (e.g., cso)
  • Choice value prefix: Set a unique range to avoid conflicts

Critical: Use ONE publisher per project. Multiple publishers create a mess when components reference each other across solutions.

Environment Strategy

For enterprise CE projects, use at minimum:

| Environment | Purpose | Solution Type | |------------|---------|---------------| | Dev | Active development, unmanaged solutions | Unmanaged | | Build / CI | Export and package solutions | Unmanaged to Managed export | | Test / QA | Testing managed solution deployments | Managed | | UAT | User acceptance testing | Managed | | Production | Live system | Managed |

Key Rules

  1. Never develop in production — always deploy managed solutions
  2. Never deploy unmanaged to Test/UAT/Prod — always use managed
  3. Use a dedicated Build environment for clean managed exports
  4. Refresh Dev from Production periodically to catch drift

Version Numbering

Use semantic versioning for your solutions:

MAJOR.MINOR.BUILD.REVISION
  1  .  3  .  0  .  4
  • MAJOR: Breaking changes, schema modifications
  • MINOR: New features, new entities/fields
  • BUILD: Bug fixes, flow updates
  • REVISION: Auto-incremented by pipeline

ALM Pipeline Setup

Basic Pipeline with Azure DevOps

# azure-pipelines.yml
trigger:
  branches:
    include:
      - main
 
pool:
  vmImage: "windows-latest"
 
steps:
  - task: PowerPlatformToolInstaller@2
    displayName: "Install Power Platform Tools"
 
  - task: PowerPlatformExportSolution@2
    displayName: "Export Unmanaged Solution"
    inputs:
      authenticationType: "PowerPlatformSPN"
      PowerPlatformSPN: "Dev-ServiceConnection"
      SolutionName: "ContosoCore"
      SolutionOutputFile: "$(Build.ArtifactStagingDirectory)/ContosoCore.zip"
 
  - task: PowerPlatformUnpackSolution@2
    displayName: "Unpack Solution"
    inputs:
      SolutionInputFile: "$(Build.ArtifactStagingDirectory)/ContosoCore.zip"
      SolutionTargetFolder: "$(Build.SourcesDirectory)/solutions/ContosoCore"
 
  - task: PowerPlatformPackSolution@2
    displayName: "Pack Managed Solution"
    inputs:
      SolutionSourceFolder: "$(Build.SourcesDirectory)/solutions/ContosoCore"
      SolutionOutputFile: "$(Build.ArtifactStagingDirectory)/ContosoCore_managed.zip"
      SolutionType: "Managed"
 
  - task: PublishBuildArtifacts@1
    displayName: "Publish Artifact"
    inputs:
      PathtoPublish: "$(Build.ArtifactStagingDirectory)"
      ArtifactName: "solutions"

Common Pitfalls

1. The "Active Layer" Trap

When you import a managed solution and then make unmanaged customizations on top, you create an active layer. This causes:

  • Managed solution updates to be silently overridden
  • Confusion about which layer is "winning"
  • Difficult-to-debug form and view differences

Fix: Remove active customizations before importing updates. Use the solution layers view in make.powerapps.com to identify and remove active layers.

2. Solution Checker Failures

Run Solution Checker before every deployment:

  • Navigate to Solutions in make.powerapps.com
  • Select your solution, then Solution Checker, then Run
  • Fix all Critical and High issues before deploying

3. Connection References in Managed Solutions

Connection references in managed solutions need to be configured per-environment:

  1. Create the connection in the target environment first
  2. During managed solution import, map each connection reference
  3. Automate this mapping in your pipeline with environment variables

Checklist for New Projects

  • Define publisher and prefix
  • Plan solution segmentation
  • Set up environment strategy (Dev, Build, Test, UAT, Prod)
  • Configure source control repository structure
  • Create CI/CD pipeline templates
  • Document solution dependency order
  • Set up Solution Checker in pipeline gates
  • Establish version numbering convention
  • Train the team on solution import/export procedures

Summary

Investing time in solution management architecture upfront pays dividends throughout the project lifecycle. Start with a segmented solution strategy, enforce managed deployments from the start, and automate everything with pipelines.

#dataverse#solutions#alm#devops#managed-solutions