As I tweeted a couple of days ago, my head has been spinning with Dynamics 365 for Enterprise (D365E) recently 🙂 :

Definitely a very #MSDYN365 packed day - passed MB2-716 and successfully upgraded our organisations 2016 instance to 8.2! Phew! 😅

— Joe Griffin | #ProCodeNoCodeUnite (@joejgriffin) April 7, 2017

I took a detailed look at the upgrade process involved as part CRM Online organisations last year, and thankfully the process has not changed much. Indeed, the whole upgrade seemed to complete a lot quicker - 40-50 minutes as opposed to over an hour, which was nice to see.

As part of any planned upgrade, you should always endeavour to perform a thorough test of your existing application customisations with an environment running the latest version - either with a spare sandbox instance on your subscription or by spinning up a 30 day trial of D365E. We were quite thorough as part of our upgrade process with respect to testing, and fortunately, the upgrade completed with only some minor issues left to deal with. For those who are contemplating or have their upgrade scheduled in over the next few weeks/months, then there will be a few things that you may need to be aware of ahead of time to avoid you having to deal with any potential problems with your new D365E deployment. With this in mind, here are 3 things from our upgrade process that bear in mind before you make the jump to 8.2:

Switch Off Learning Path in System Settings To Prevent Annoying Popups

Attempting to keep up with the number of new features that Dynamics 365 brings to the table is a colossal task. It was for this reason that I only became aware of the new Learning Path feature. Boasting functionality that is not too dissimilar to products such as WalkMe and available across the whole spectrum of the D365E experience (Web Client, ISH and Mobile/Tablet app), the feature is designed to provide a guided means of training new application users on how Dynamics 365 works within the specific context of your business. Induction and new user training can be one of the major hurdles that can affect the success of a system deployment, so having a very contextualised, built-in and guided process of training and reminding users how to complete tasks within the application can surely be an important tool for any organisation to have at their disposal.

Unfortunately, the feature looks to be a little bit too intrusive from an end user experience viewpoint, as leaving the feature enabled post-upgrade will result in the application attempting to open pop-ups through your browser of choice:

To disable the feature until you are ready to start rolling it out across your business, then you have two options at your disposal:

1. Direct your end-users to select the Opt Out of Learning Path option from the gear icon on the D365E sitemap area:

   

2. Go to System Settings and then select No under the Enable Learning Path option. This is the recommended option, as it will disable the feature across the board for all users:

   

Modify Your Error Notification Preferences Options for all users

Error messages can occur occasionally within the web application. Generally, these will take the form of the Send Error Report To Microsoft variety, and can result from either a problem within the application itself or an error that has been caused by a developer customisation (e.g. JScript function, Sitemap amend etc.). The default setting for this is that users will be prompted before an error report is sent to Microsoft on these occasions. Having the default setting enabled can prove useful when diagnosing issues with the application, but could cause problems and distress for your end users if the application is throwing them regularly.

Whether due to customisations involved as part of the above upgrade system or a fault with D365E itself, these error messages seem to be throwing a lot more often in the latest version of the application; in fact, almost pretty much every time a user leaves a record. The error messages are sufficiently non-descript and lacking any reference to customisations made to the system (such as a JScript function name) to indicate that it could be a problem with the customisations itself. By selecting the option to send the error reports to Microsoft, you can ensure that these errors will be looked into and hopefully addressed as part of a security update in the future. But I would recommend, if you are upgrading to D365E, to ensure that have selected the Automatically send an error report to Microsoft within asking the user for permission on the Privacy Settings page to ensure that your end-users are not getting bombarded with constant error messages:

Don’t Upgrade Just Yet If You Are Using Scribe Online

Scribe Online is currently one of the de-facto tools of choice if you are looking to accomplish very basic integration requirements around CRM. The tool enables you to straightforwardly export your application data into external sources - whether they are SQL-based data sources or even completely different applications altogether. I have not had much direct experience with the tool myself, but I can attest to its relative ease-of-use; I do take issue, however, with how the tool operates within a CRM environment. For example, it creates a custom entity directly within your CRM instance within the default solution, using the default solution prefix (new_). Most ISV solutions instead deploy any required customisations out to the application using the much better supported and best practice route of Managed Solutions, allowing application administrators to better determine which components are deployed out as part of a 3rd party solution and to expedite any potential removal of the solution in future. Having said all that, Scribe Online should be your first port of call if you have a requirement to integrate with external systems as part of your CRM solution.

Now, I deliberately avoided mentioning D365E in the above paragraph, as it looks as if the Scribe Online tool has issues either as a direct result of the upgrade process involved with D365E or due to Scribe Online itself. Shortly after upgrading, the application/Scribe Online will modify the properties of your entity records to set the modifiedon field to the same value for every single entity record. If the number of records in your entity exceeds the default amount of records that can be returned programmatically (thereby requiring the use of a paging cookie), then Scribe will return an error message similar to the below when it next attempts to run your RS solution:

Unable to get the next page of data. Dynamics CRM has not advanced the page cookie for Entity:new_mycustomentity, PagingCookie: <new_mycustomentityid last="{A56661B7-C969-E611-80EF-5065F38A8A01}" first="{797EAA25-1645-E611-80E1-5065F38A4AD1}" />

This issue looks to be occurring for other organisations who have upgraded as well, and Scribe have published an online support article with a suggested workaround for this situation provided by Felix Chan:

To work around the issue, we used JavaScript with the Microsoft Dynamics 365 Web API to update all of the account records by changing the value of a field we don’t use (e.g. telephone3) from null to "" (which translated back to null). Needless to say, this effectively updated the modifiedon datetime stamp. It also resulted in the change to Telephone 3 to show up in the Audit History of each account record.

The above Workaround is all very well and good if you dealing with a small number of records and have the appropriate knowledge on how to implement some form-level JScript functions. But my concern will be for organisations who lack this knowledge and are instead left with a solution that does not work. Despite not having firm proof of this either, I suspect that the issue is a fault with Scribe itself and not as a result of the upgrade. This is based solely on the value of the modifiedon field being well after the upgrade has taken place and during the time when our RS Solution was running. Scribe need to ideally acknowledge the existence of this issue and confirm what is causing the error to take place; but, in the meantime, if you are reliant on Scribe Online for business-critical integrations, I would strongly recommend to hold off on upgrading until this issue is acknowledged or until you can identify a replacement service that does not suffer from this problem. In our case, we were only using Scribe Online to backup our application data to an Azure SQL database and were instead able to get up and running quickly with the rather excellent Dynamics 365 Data Export Service.