Automated audit of Dynamics 365 configuration during pre-sales

András Fördős
4 min readApr 5, 2021

When responding to a request for proposal (RfP) related to an upgrade or extension project, it is desired to gain insight into the state of existing customization to tailor estimations and identify risks.

With this post, I will show an organized and rapid way to get those morsels in a repeatable and controlled manner. Pre-requisite is, that either you have access to DEV instance(s)/solution file(s) or the customer is willing to help out with the initial steps.

Overview

This example process has a dependency on the official static analysis tool called Solution Checker. In case you are not familiar with it, or don’t know how to set up the service, please check the documentation (LINK). To access the service, you will need a tenant with PowerApps or Dynamics 365 licensing. This could simply be a trial in your preferred region if no production ones are available, after verifying applicable data regulation needs.

The process has 4 main steps — some skippable depending on the situation — for which I will provide PowerShell snippets to help you get started:

Collect

In case no real solution segmentation was practiced beforehand, you may be looking at one single DEV instance with 80+ unmanaged solutions. Even if things look bit healthier, building a fully automated process provides the benefit of eliminating human error. The aim here is to:

  • gather all relevant solutions, eg not the Default
  • download the solution files
  • collect ZIP files into a single location

Alternatively, if the potential customer has already set up source control practices and the decomposed solutions are stored under Git, the above steps can be replaced with the Solution Packager (LINK) reconstructing the required ZIP files.

Analyse

As mentioned above, for this example I am using the Solution Checker service to gain valuable insights. When invoked with code and not through the UI, the service provides access to additional settings, such as the rule set to be used.

Merge

The output of the analysis service is a ZIP file containing one or more SARIF JSON files. There are multiple ways to interact with them, but for the sake of an end-to-end solution, I will be merging the separated reports into one single CSV file, making easier to digest the outcomes.

To do so, first we need to create an empty CSV with predefined column headers, based on the information we are expecting. This CSV template will be populated by us. The headers I am expecting are described by the Solution Checker documentation (LINK) with my addition of:

  • Report name for audit purposes
  • Solution for filtering purposes
  • Qualified name, which seemed like an interesting extra from the SARIFs

Visualize

To streamline the final steps, we need to prepare a basic PowerBI report with meaningful visuals and details, based on what you are usually looking for. My basic report looks as follows:

Make sure to use the identified CSV template as the input, as simply by swapping it each time, we will have readily available visualization of the analysis at our disposal without any extra effort.

Aim to use visuals, which are informative even when drilling down on any of the cards, mixing well the dynamic and static capabilities of PowerBI reports.

Additional thoughts

  • Code analysis: naturally, the above process can be extended or replaced with different code analysis tools and checks (eg SonarQube, JSLint) to enhance the power of the report - the above flow is just the basic skeleton to gain the first morsels
  • Tooling: the given examples used PowerShell but due to the abundance of available tooling, the concept can be ported and recreated with your preference, eg within a simple Azure DevOps pipeline
  • Dependencies: I have built upon the Microsoft.Xrm.Data.PowerShell and Microsoft.PowerApps.Checker.Powershell modules, but you can swap them or even replace with your own ones to interact with APIs, if there are limiting restrictions
  • Reporting: I am using PowerBI due to my predilection and that it fits well with the Microsoft stack, but yet again, the desired dashboard can be recreated in any other tool or service, if it gives you the required flexibility with decoupling and swapping inputs within seconds

--

--