Welcome to the second post in the 5 bite-size shareable that you should know. This time we’re talking about solutions. A Solution is a container in which we can add in our customization’s, (Forms, Fields, views) it can contain security roles, site maps, Applications, Flows, etc. Solutions is an important piece to learn and master as you forge ahead on your journey with Dynamics 365, Power Automate, and Power Apps. So let’s dive into 5 quick pieces of knowledge to learn.

The Default Solution

The default solution is your entire Dynamics 365/CDS environment in one solution. To view the default solution, navigate over to Settings Customizations > Customize the system.

When to use it: Rarely

1. When you want to create a “Gold” copy of your environment. If you are about to test out some somethings and want an option to roll back too. Consider exporting a unmanaged copy of your Default solution. This will allow you to roll back a customization that you might have introduced into your environment.

When Not to use it: 99% of the time

1. All customizations that you intend to deploy to another environment, or even if you are not going to deploy them to another environment is a good practice to always use a new solution with building customizations for Dynamics 365, CDS and the Power Platform. Using a new solution ensures that any customizations you develop within CDS or Dynamics 365 are automatically included which reduces risk, but when it comes to Power Automate the CDS connector has some enhanced features when you build your flows from within a solution.

Version: more than just a number

What is in a version number? It can be pretty basic and it can quickly be forgotten or overlooked. However, it is an important piece of your solutions Application Life cycle Management (ALM). It acts as a piece of information that allows you to Audit and track the solution and should be a living number that tells its own story. The default option from a solution recommends something like 1.0.0.0. You can also shorten it to 1.0. Here is a format that I like to use.

Version: 2019.256.22.1  

Lets break this one down:

2019:  Year
256: Day of the year
22: Current Sprint
1: Number of builds

So reading this version number we can immediately see that it was built on the 256 day of 2019 in Sprint 22 and was the first build of the sprint. From here I can immediately jump over to Azure DevOps into Sprint 22 of 2019 and see what User Stories were part of that build.

The next steps with a version number are that it can be managed and incremented based on a Build and release from the Azure DevOps pipeline. However, that is a topic worthy of an entire blog on its own and won’t be covered here.

Do not add All Assets

When adding in an existing entity to a solution there is a checkbox in right hand corner labeled ‘Add All Assets’. If you leave this checked, everything about the entity will be added to the solution. All of the fields, forms, views, etc. This is not a preferred practice for a couple of reasons.

1. It introduces a risk that a customization that isn’t finished would be deployed with your solution. Maybe a new form that you were working on but didn’t quite finish.
2. It increases the size of your solution file which has a few impacts. The speed of the import to the new environment and there is a size limitation on how big your solution file can be.
   1. 29 MB for Online.
   2. 6 MB for On-Premise*
      https://docs.microsoft.com/en-us/dynamics365/customerengagement/on-premises/developer/create-export-import-unmanaged-solution#maximum-size-of-solution-to-import
      

My preferred approach is to only choose the objects that you modified when building your solution. So when adding the Account entity to a solution, instead of leaving “Add All Assets” checked. Remove the checkmark and add in just the updated view, or field that you have modified. This will improve the overall health of the solution by only deploying the delta of what has changed but keeps your solution size down as well.

The bottom line here is, just say No to adding all Assets to your solution. Take the steps to add in just the updated components needed to the solution.

Use the Solution Checker

The Solution checker is the new kid on the block to help you improve your solution health. When using it, you will also improve your own skills and learn from the issues that it flags for you. At the User group Summit in Orlando in October, Mark Smith and Steve Mordue say down with Matt Barbour from Microsoft and one of the topics in that discussion was the Solution checker and how Microsoft is constantly investing in this living tool. Check out that conversation here.

Why use the Solution Checker:

1. It runs a series of checks against your solution that contains all of the known issues, best practices that Microsoft is aware of at the current moment.
2. After it completes it outputs a report (and emails it to you) that breaks down the issues found in a high, medium, low categories.

I’ve just started to dive more into the Solution Checker more and finding ways to merge it into our end of sprint requirement and the definition of Done. As a start we’ve made a rule that no solution can be deployed from Dev. that has any items categorized as High. Medium categorized items need some level of justification as to why it should be deployed.

Check back later and I’ll do a deeper dive into the Solution Checker. For now if you want to learn more, head over to the Microsoft Docs site here.

Use a Publisher – Say no to new_

• Why would you use a Publisher:
  1. It allows you to preset a prefix for all of your new customizations. This means you can ditch the new_ prefix that comes with the default publisher and allows you to have a prefix that has value or meaning to your organization.
  2. Multiple Publishers means multiple prefixes. If you want to use a separate prefix per Project or per developer. You can create multiple publishers to allow you to have a distinction between two different purposes.

Photo by Daniel Cheung on Unsplash