When deploying solutions in the Microsoft Dynamics 365 Power Apps maker portal from non-production to production, it can often feel like you are navigating a complex maze of configurations, customizations, versions, and dependencies. In this blog, I will break down key steps to simplifying your D365 solution deployment journey, empowering you to manage deployments with confidence and avoid common pitfalls.
Keep Common Components Within Their Own Solutions
Over the years of performing numerous solution deployments, I have realized having one large solution with all related components can make it difficult to maintain and deploy enhancements down the road. Separate solutions make it easier to manage components and deploy changes when needed. It also allows for quicker deployments during a phased rollout since the deployment publisher does not need to check every component each time there is a change. I find deploying solutions in the below outlines order helps avoid dependency issues. After that, you should be able to deploy updates to these separately at any point into your Sandbox and Production instances.
A. Data Model Solution – This solution will contain all the application components related to the Dynamics 365 application with key items like:
I. Model-Driven Application
II. Site Maps
III. Tables
IV. Dashboards
V. Columns
VI. Relationships
VII. Global Option Sets
VIII. Forms
IX. Business Rules
X. Custom Security Roles
B. Process Solution – This solution will contain all the processing components related to the D365 application with key items like:
I. Power Automate Cloud Flows
II. Connection References
III. APIs
IV. Plug-ins
V. Workflows
C. User Interface Solution – This solution will contain all the ‘custom’ components related to the Dynamics 365 application with key items like:
I. Web Resources (HTML, JavaScript, Images)
D. Metadata Solution – This solution will contain tables that use custom ribbon button components and metadata for any custom code related to the tables.
Common Component Ownership
Make sure to assign the ownership of solution components requiring an owning user (such as Power Automate Flows or Business Process Flows) to a dedicated licensed admin service account to prevent future issues. In my experience, I have seen instances where a flow is owned by a user who leaves the company, and their account gets disabled. This caused the flow to stop working which resulted in unnecessary troubleshooting to resolve the issue. Using a system admin account that always remains active across all environments avoids this risk.
Configure Connection References
For components like Power Automate Flows that require connections to other systems, using Connection References ensures consistent connections across all environments during deployment. This approach simplifies management and reduces the need for manual reconfiguration. Again, if personal connections are used and the user’s account is disabled, the flow may stop working.
Create A Custom Solution Publisher(s)
During solution development, there may be cases where multiple individuals or companies (such as different consultants) may contribute to the work. Using custom publishers helps clearly identify the developers or teams responsible for each solution, improving traceability and accountability.
Develop With Unmanaged Solutions, But Promote As Managed Solutions
One of the most common challenges when talking with developers is whether they should promote solutions in the Sandbox and Production environments as managed or unmanaged. My recommendation is to always develop in an unmanaged solution and promote to Sandbox and Production as managed. This prohibits a user with elevated permissions from making changes to solution components, which can cause unnecessary layers. Once unmanaged solution layers are introduced into a managed solution it can be difficult to troubleshoot and cause issues down the road. Additionally, solutions are required to be managed if you plan to use deployment pipelines.
Build Automation With Deployment Pipelines
Deploying through Automated Pipelines helps reduce manual steps, minimizing deployment errors and saving time. Prior to pipelines, developers would manually export a solution out of Development and manually re-import into Production environments. This was not ideal and was very time-consuming. Now with automated staging and versioning control, it is literally point and click to move changes as with the screenshot below:
