How To Successfully Develop Your Microsoft Dynamics 365 Solution Deployment Strategy

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 Dynamics 365 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.

• 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
• 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
• 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)
• 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:

In conclusion, developing a successful solution deployment plan can be as important as the actual development work itself. The strategies I have mentioned in this article will help developers within organizations reduce risks and also maximize the value of their Dynamics 365 solutions. This is done by keeping solutions clean, maintaining consistent versions between all environments, and keeping the deployments as straightforward as possible. Thank you for reading, and if you have any questions please reach out to New Dynamic for assistance.

By Mike Mitchell – Senior Consultant

Working With New Dynamic

New Dynamic is a Microsoft Solutions Partner focused on the Dynamics 365 Customer Engagement and Power Platforms. Our team of dedicated professionals strives to provide first-class experiences incorporating integrity, teamwork, and a relentless commitment to our client’s success.

Contact Us today to transform your sales productivity and customer buying experiences.

The post How To Successfully Develop Your Microsoft Dynamics 365 Solution Deployment Strategy appeared first on CRM Software Blog | Dynamics 365.