Dynamics 365 Performance Considerations Series 1 of 2

Dynamics 365 for the Mobile Age

In a fast moving mobile world, performance and a responsive User Interface in Dynamics 365 are key items when discussing user adoption, Users require access to their data on a multitude of devices and locations around the world in this Series of 2 l will explore some key considerations.Implementations need to be designed to work efficiently on any device that access Dynamics 365. Whilst working on Dynamics 365 projects over the last 4 years or so, and more recently Dynamics 365, the technology surrounding a Dynamics 365 implementation has grown and so too has the functionality provided with Dynamics 365 compared with Dynamics CRM 2011.

Microsoft supports access to Dynamics 365 with multiple different browsers and devices through feature rich mobile applications for either iOS, Android and Windows.

Microsoft support access to Dynamics 365 via:

Internet Explorer (10 or 11)
Google Chrome (Latest release)
Firefox (Latest release)
Safari on Mac OS X (Latest release on latest OSX release)
Native iOS apps for iPad or iPhone
Native phone and tablet apps Andriod and Windows Apps
Microsoft Dynamics 365 App for Outlook
Microsoft Dynamics 365 Client for Outlook
Interactive Service Hub (ISH)
Unified Service Desk (USD)

My Dynamics 365 is slow

When discussing performance with the customer in the context of Dynamics 365, this is usually because of statements “the system is slow” or “the system freezes when opening a form”  from the end Users.

As a Dynamics 365 Specialist, I know that there are a multitude of factors that can be the cause of these types of issues. The problem is identifying which factor is causing the issue; generally this can be down to one of the following:

Network Performance (Speed and Response time)
Server Performance (Dynamics 365 Server and processes)
Client Performance (Desktop/Laptop/Mobile)

Dynamics 365 customisations

One of the key factors when a designing Dynamics 365 solution is for the consultant to be aware of the factors and design the solution in such a way it will help prevent or minimise the above factors where possible. Consultants can do this by thinking about the customization they are building or have discussions with the customer about the devices that the end users will be using to access Dynamics 365. If the system is unresponsive for a period of time or takes a while to load a form, this is going to decrease users perception of the application,user adoption will decrease and drive a negative view of the implementation with the customer, so your design is the best place to start.

This blog will provide you with an insight to what I have learnt over the last 4 years or so when designing Dynamics 365 solutions to minimise the impact of Network performance and Page Load times. I will also include a few links to tools that you can use to help diagnose issues with your implementation or references to new functionality to aid with system performance in Dynamics 365.

Network Performance

When discussing Network performance with the customer in the context of Dynamics 365, this can usually relates to how fast can affect Dynamics 365 page loads or the page becomes unresponsive. The two items related to Network performance generally affecting load times are:

Latency Response Times to and from the client and server, generally referred to as a ping measured in milliseconds (ms). This can be affected by other network traffic accessing the same network and the number of server connections.
Microsoft state for Dynamics 365 that a latency of 150 ms or less is the recommended value.

Bandwidth The maximum speed/size of the Network connection (measured in bits/second i.e. 20Mb/s) which data can be transferred across between source and target. If the Network bandwidth is set at 1Gb/s (Gigabit) then it can transfer a 1 GB (GigaByte) file in approximately 7.4-8 seconds. The Upload bandwidth is usually the limiting factor and not the download (as in most scenarios this is a lot bigger than the upload).
Microsoft state for Dynamics 365 that a bandwidth of 50KBps (400 kbps) or greater is the recommended value.

WiFi networks and 4/3G mobile networks generally have a higher Latency and lower Bandwidth than a wired Ethernet cable connection; I recommend using a wired Ethernet connection over a WiFi connection (where available).

That being said some Internet connections may actually have a higher latency due to the remote location and distance from the ISP server regardless of whether they connect through WiFi/Ethernet or 4/3G.

Identifying Network Performance Issues

As a consultant, usually you can make the recommendation to the customer to use one type of connection over the other (if applicable), but this is usually out of your control. To help identify Network Performance issues – you can run Latency and Speed tests at different points or methods of access on the network.

Speed Test – Bandwidth

For Latency and using the web client, you can use the diagnostics tool to help measure your latency along with some other additional browser tests. Whilst this performs a Bandwidth test, you are better off using a service like typing speed test into Google.

Dynamics 365 Diagnostic Tool – Measure Latency

To access this feature in Dynamics just add the following to the end of your organisation URL:


https://FULL DYN365 URL/tools/diagnostics/diag.aspx


Server Performance

The Microsoft Dynamics 365 server really only implies meanings to On-Premise installations, as you have no control over the hardware specifications with the Online version as Microsoft control this on customers behalf

When designing and building the actual solution, this I can help provide some insight into as this topic encompasses both the online and on premise versions of Dynamics 365.

There are three main items to consider when designing and building Dynamics 365 solutions when discussing Server performance and best practice, which I will discuss separately. These are:

Plugins and Workflows
Data Query Optimisation
The Security Model

When retrieving data Dynamics 365 uses its own API to convert client or server-side requests into SQL queries against the back-end SQL database; when a request is made, the first query is made against security access rights that the requesting User has too. In the following example a User tries setting the Parent Account for a particular Contact, the system needs to check whether the User has the Append privilege on the Account and the Append To privilege on the Contact.

Security Roles

The Security Model in Dynamics 365 can be as simple or complex as you want it to be, with different levels for Business Unit hierarchies, Manager or Positional Hierarchy. Users can access Dynamics 365 with Security Roles which they are either:

Assigned to (via the User record)
Inherited From (Teams they are Member of)
Record access which are directly or indirectly shared with them
SecurityRoleSecurity Roles in Dynamics 365 are additive and the least restrictive permission wins. To query the Security Roles of each User, Dynamics 365 will query the Roles through multiple layers to return the permissions for what they are allowed to see from an interface perspective and from a data (records) perspective. This order is the following :

1.User Security Roles and privileges
2.Teams Security Roles and privileges (and the Users membership of those Teams)
3.User’s Business Unit, and their Teams’ Business Units (for Teams that have Roles with access level of Business Unit or Parent: Child Business Unit)
4.Records explicitly or implicitly shared with User, or User’s Teams (Access Teams) therefore if a User has User/Team read access to an Account that is Owner by someone else in an Access Team they are a member of, this query will take a lot longer to retrieve than an Account owned by them as their own security role would allow them to see the record.

To assist query times, Dynamics 365 does cache some of the access information (i.e. whom has which Security Role and Owner Team membership) to speed up the query as the information exists – but items like membership to Access Teams is not cached and is ultimately slower to query, and any records displayed to the User will take longer to return data.

My recommendation is to keep security to a minimum where possible, unless there is a business compeling case/requirement that requires that type of data (or functionality) to be restricted to certain Users (for example Deletion rights to a specific entity is restricted to Data Admins). Performance impact will be negligible for solutions where Access is the least restrictive.

Plugins and Workflows

In the Microsoft Dynamics CRM 2011, a lot of the deployments where On Premise deployments, Workflows where only Asynchronous and bespoke plugins and JavaScript where your best and worst friends where business requirements could not be met using out of the box functionality. The potential for bad code (from a performance perspective) was ever so much more present back then, different developers has different coding styles and there were always more than one way to meet a requirement through code.

Plugins could some time take a while to execute depending on the complexity and the queries/actions they undertook, Workflows could be stuck in an infinite loop or have multiple sat in waiting state – until the action/date was reached; each of these could would have a negative impact on the Server.

Microsoft CRM 2013 to Microsoft Dynamics 365

Microsoft introduced new functionality with each version of Dynamics CRM since the 2013 release, this release brought in:

Business Process Flows
Business Rules
Synchronous Workflows

The aim is to provide system customisers with the ability to meet greater or more complex requirements whilst using the out of the box functionality.

Business Rules and Business Process Flows aim to break down the dependency of using client side JavaScript and guide the Users down a correct path to enter data. Synchronous Workflows removed the full dependency on writing plugins to meet requirements as the Workflow would execute is the same manner as a plugin. These pieces of functionality would reduce the additional code overhead on the server as no additional code would be required as the code would effectively be written in a supported and consistent way by Microsoft Dynamics 365.

I recommend using out of the box Dynamics 365 where a Dynamics365 architect will know when a requirement cannot be met and will require bespoke automation to be written. Out of the box provides value to the customer regarding the solution; they should not be paying for your time to re-write the functionality if it can be met using out of the box functionality (say a Synchronous Workflow over a Plugin). They should be paying you utilise and configure the tools to meet their requirements. Why re-invent the wheel, it creates an administrative overhead in maintaining the code for future releases where Microsoft will support any functionality out of the box for future releases.


Popular posts from this blog

How to Query Microsoft Dataverse Data using SQL from Power BI or SSMS

Users Unable to See Flow Button and run On Demand workflows in Dynamics 365 CE

How To Deploy Dynamics App For Outlook (On-Premise)