What is the solution version number used for?

A recent thread of discussion on the CRMUG forums about this topic got me thinking – here is my take on the subject.

For the smaller clients with no integration, I think there is value in using the current date in the solution version number so when you export it so that you can easily keep track of which file in your downloads folder is the right one. A quick acknowledgement to @Gus Gonzalez's for making that suggestion. End users can easily comprehend it and it adds value to them. A solution file can have literally anything in it and the (typical) version number does nothing to help you with figuring out what is major/minor/patch or resolving dependencies. By using Gus's technique, the date of the solution is built into the exported file name. By using Gus's technique, you avoid having multiple copies of a file called "SolutionName_1_0_0_0.zip" and trying to figure out which one is relevant. I would argue that for the people creating solutions for small(er) organizations, it is not easy to make the distinction of major vs minor. Can anyone here define how many fields on a form must move before you cross the threshold from a patch to a minor release, or how many business rules must be changed before it becomes a major release?

But for a company that has a staff of developers that depend on integration with other systems and have governance policies, we should consider the benefits to the version number with a traditional approach. For many of my past projects, I have clearly agreed with @Ben Bartle's position because I come at this as a developer. The reason has to do with traditional software development practices: When writing applications that have dependencies on a multitude of libraries (.DLL's), then keeping track of the version number helps you identify whether an update to a library will significantly impact your application. With a DLL it is easy to define what is major, minor or a patch based on best practices.

For a consultant that is configuring systems for many clients, I would recommend that you have the name of the client for the solution name, and put the D365 version in the first two decimal positions of the version number, and date in YYMM.DD format in the last two positions. This makes it easy to tell which version of D365 you exported the solution from (which could be significant if the development area is not in sync with staging and production) and the date it was exported.

To bring this point back into context of this discussion, when you modify a D365 solution and then promote it to production, you are actually updating the API endpoints. Consider what happens when you alter the behavior of workflows, deprecate entities/fields, or make the field length shorter. When you promote that solution into production, you run the risk that integration code will break.

Personally, I have been putting the date in the solution's Information/Description field.  While this is not as pretty as using the version number as a proxy for a date, it serves it purpose because you can see the solution description gets updated in the production system. The only downside with that approach is that you have to either import the solution file to see the description containing the date, or rip apart the zipped solution file and read the XML files.

With respect to keeping track of whether the solution file contains a major/minor/patch to a system, that is something everyone should be documenting anyway regardless of whether you go with Gus or Ben's recommendation. By keeping a log of changes and/or implementing a full version control system between development/staging/production, you must be communicating your changes to your testing staff or your end users, no matter how small the change is. If users detect a change that you were not in control of, they might think the system is unstable, and they will lose confidence in your system.
​

Why is D365 running so slow?

I hate to say it, but your system performance depends on many things. Here is my check list of possible issues, ranked from most to least likely (in my humble opinion):

• Synchronous workflows and plugins - You could test this (in a sandbox) by deactivating them and see if there is a difference in performance.
• Check your Settings/System Jobs to see if you have a lot of activity in there (especially failures). If you have years worth of system job data, I highly recommend you set up scheduled Bulk Record Deletion jobs.
• Data duplication rules – how many published rules do you have? Turn them off and see if there is a difference.
• Browser plugins (including antivirus)
• Browser cache – depends on the browser, but highly recommend clearing your cache daily because MS is updating the form rendering engine all the time.
• Is Auditing turned on?  It could play a small part in your overall performance.
• External apps, such as PowerApps, Flows, ClickDimensions that might add load to your database. If you set up an Azure application in a different region from your CRM instance, this could impact system performance (and unnecessary cost).
• Network throughput (Bandwidth) In a recent Gartner survey, 22% of IT leaders identified networking problems as the root cause for performance issues with Office 365. I have customers that have researched their connection speed between different MS data centers and have had unexpected results. Just because you are close to the data center does not mean it will be faster.
• Time of day – Sometimes I can see a difference in performance depending on the time of day, which is likely to be related to my upstream network throughput or the data center where my D365 instance is located. The only way I could test this would be to create a dedicated data circuit between my office and my data center.
• JavaScript embedded in your form that make a lot of API calls. Use the browsers built-in performance tool to see what is happening.
• Asynchronous workflows running will add workload to your database. For example, If you have imported 100k records which might kick off 200k async workflows, then users might expect to see slow performance while the workflows are hitting your system.
• Relevance Search and Text Analytics – crawls your site to index your data. This is adding load to your system.
• Legacy form rendering – you could try to experiment with this System Setting, but be warned – MS says that legacy form rendering will be turned off.
• Server Side Sync – do you have a lot of email coming in? Are new contacts created?
• Number of rollup queries – you would see how much activity is going on in the System Jobs Log (mentioned above). This would also include things like Goals.
• Cascading relationships – Look at each 1:N relationship and see what the “down-stream” effect is of your updates.

Create a link to a new UI form

I was reading recently in a D365 CE discussion thread that someone wanted to create an email using a workflow, and the email needed to have a link to an Account form in the new UI.

This is possible if you know how to make URL parameters appear the way you want in a workflow email. Consider this: if you try to create a link in the email using the editor, and you click on the Link icon, then you do not have any options to add a reference to a record’s Global Unique ID (GUID) in the URL:

Our goal is to make a URL that contains the parameters needed to trick CE into showing the new UI form when the user clicks the link to access the account.

The URL we are trying to create takes this form:

…//xxxx.crm.dynamics.com/main.aspx?appid=&pagetype=entityrecord&etn=account&id=

Where:

    “xxxx.crm.dynamics.com/main.aspx?” is your base URL
    “appid=” is the parameter that navigates the user to the new UI
    “pagetype=entityrecord&etn=account&id=” will open the desired account record

The base URL seems easy. However, if you are following best practices, then you know it is not a good idea to hard code the base URL into your workflows. The reason is because most people have a 3 phase process to Develop a solution, test it in a Staging environment, and then deploy it into Production. Each one of those environments has its own URL. I solved that problem by creating a workflow Action in all 3 environments that holds the base URL. More on this later.

To get the App ID, open your app designer and get the GUID of the app. It follows the “/” and ends at the “#”

Now I am ready to create an Action to assemble the URL we want. I put an “aaaaa_ ” in the front of the name to make it appear at the top of the list just as an illustration for this article. 

 In that Action, I created a couple arguments for input and output. The first one is an input parameter with the Account GUID (we will get to how we get the GUID in a minute). The second argument will hold the return value.

Next, add a step to assign the return value with the base URL from above.






The second step in the action appends the necessary account parameters to the previous step. This will give us a complete URL when it is called. I could have done this all in one URL, but in best practice, I would have made the system URL a separate Action that is not promoted with my development solution and lives only in my Development, Staging and Production system so that I do not have any hard coded URLs in my workflows.


 Now when we call that Action, we need to pass in the Account GUID as a string. The solution I found was to use a free solution called Workflow Elements by Aiden Kaskela. This solution has the ability to reveal Metadata about the workflow as string values. After you download and import the solution to your system, you get some new options when you add steps to your workflows. The one we are interested in is the “Workflow – Get Metadata” which will provide the GUID of the record that triggered the workflow to start.

 


Next I created a workflow to create my email. The first step is set to run the Get Metadata feature provided by Workflow Elements. It does not take any parameters to configure. In subsequent steps in the workflow, it provides the Record ID of the account record that triggered the workflow to start.  


The second step in the workflow is to call my “aaaaa_create url to hub” action where I pass with the Account GUID as the input parameter.

The final step is to create the email that uses the EntityURL created by the previous step in the workflow and it provides just the Output parameter from the action, which contains the full URL we need.


When you run the workflow, it will now generate a full URL link to the related account for the new UI.
 

Leave me a note below if you found this useful.
​