Dynamics 365 for the Mobile Age
In the mobile age, 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 (thank you Dynamics 365 Online). Implementations need to be designed to work efficiently on any device that access Dynamics 365. Whilst working on Dynamics CRM projects over the last 6 years or so, and more recently Dynamics 365, the technology surrounding a CRM implementation has grown and so too has the functionality provided with Dynamics 365 compared with Dynamics CRM 2011.
Whilst working on CRM 2011 (at release), Microsoft only supported the following access methods:
- Internet Explorer
- Microsoft Dynamics CRM Client for Outlook
- Basic Mobile Express form (if you were lucky to have IFD implemented, this was your first mobile access to CRM).
System customisers only needed to focus on performance for these types of devices, it was not until CRM 2011 Rollup 12 that additional browser support was introduced.
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 consultant, 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 customisation
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 6 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.
Microsoft Resource: Verify network capacity and throughput for Dynamics 365 clients
When discussing Network performance with the customer in the context of Dynamics 365, this can usually relates to how fast can affect CRM 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.
Request A needs to travel from client T to target server Z, where the Request will travel through various ISP servers U, V, W X and Y before reaching its destination and a Response is given by the target server Z.
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 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
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 without paying a lot of money like Azure Express Route and more additional premium services (i.e. to be on your own set of dedicated servers in the MS data-center).
I have not worked with On-Premise now for a few years in great honesty, my focus is mainly for Online Deployments so I cannot provide any tips or tricks than the standard Microsoft resources related to the hardware or software recommended requirements for implementing Dynamics 365 (except do not touch the SQL DB!).
But – 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:
- The Security Model
- Plugins and Workflows
- Data Query Optimisation
The Security Model
When retrieving data – CRM 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.
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
Security 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 :
- User Security Roles and privileges
- Teams Security Roles and privileges (and the Users membership of those Teams)
- 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)
- Records explicitly or implicitly shared with User, or User’s Teams (Access Teams)
So from a record perspective – 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 you can, unless there is a business 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
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.
CRM 2013 to Dynamics 365
Microsoft have introduced new functionality with each version of CRM since the 2013 release, this release brought in:
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.
I recommend using out of the box Dynamics 365 where you can – a good consultant, developer or 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.
If you are using Auditing in the system – do you need to Audit the following?
- User Login Access
- Every Entity
- Every Field (for each Audit Enabled Entity)
Only Audit what you explicitly need to Audit, as creating the audit records may not have an immediate performance hit, over time the system will slow returning all the audited data over a period of time when viewing the Audit History.
Data Query Operations
Microsoft Resource: Analyze and improve data query performance
For each Entity in Dynamics 365, certain queries could take a long time to retrieve data or perform actions (i.e. the standard CRUD operations – Create, Read, Update and Delete) . Microsoft defines a long running query as a query that takes three seconds or longer to complete. Typical examples of a component that can have a long running query is a plug-in with custom Fetch-XML or a sub-grid or view.
With Dynamics 365/CRM 2016 Update 1, System admins can add optimisations which aim to help reduce the amount of time the long running query takes to load. From a database perspective, optimisations added through the front end add one or more Microsoft SQL Server indexes. This is a new item of functionality which previously required a support ticket with Microsoft Support to identify the long running queries and to be able to create indexes. I have not yet used this piece of functionality – but I will be investigating over the next few months.
Client Performance (Desktop/Laptop/Mobile)
The Clients Machine
Hardware and software requirements are the two important items when considering the clients machines that are used to access Dynamics 365 via the Web Client, the following considerations should also be considered for the Outlook Client except for the Browser Items as Outlook uses IE as a rendering engine. The following are my main recommendations to get the best performance from using the Outlook or Web client; these recommendations relate to a Windows PC only such as a desktop, laptop or surface.
Windows Hardware requirements
The following items can have a massive impact on the Page Load times from a hardware perspective:
- Processor – 4/8 cores (The faster the processor/number of cores, the faster the page can render on the screen)
- Ram – 8GB (the more the better and not using the Hard Drive for virtual memory)
- Solid State Drive (generally Windows/OS’s run faster than on a mechanical hard drive)
- Network Connection – Ethernet Cable Connection over a WiFi or 3G/4G signal (this will help with both greater bandwidth and reduced latency)
- Monitor – 1920×1080 (p if Europe!) for best resolution and display as Dynamics 365 dynamically increases or decreases the resolution which can freeze the display as it changes.
- 64 bit windows – allows for greater memory usage by Internet browsers and not restricting an upper limit of 4GB Ram
- Windows 10 – this is generally faster and cleaner OS than Windows 7
- Edge over Chrome/IE/Firefox, Edge is generally a faster browser for rendering and displaying web pages (this is different for System Admins as some functionality still does not work properly in Edge)
- Latest version of each browser with minimal addins/plugins running
- Keep Zoom Level at 100/125%
- Latest windows updates
- Latest Dynamics 365 Outlook Client updates
Mobile Device requirements
I have worked on many Dynamics CRM projects and throughout the years, Mobile device usage and access to CRM has grown especially with Microsoft encroaching into the CWR/Resco arena with its Mobile Phone and Tablet applications which are now starting to provide fully offline functionality. Providing a recommendation is still quite hard – and it also depends on which OS is used.
I will admit that I use iOS, I use iOS devices day in and day out. I have used Windows and Android also in previous Jobs/personal use and found iOS to be the simplest and the Apps are built work, and the Microsoft Office 365 suite of Apps are second to none. I do however do not have the latest devices; I use a iPhone 6 and an iPad Air (1st) running iOS 10.3 (at time of writing this blog) and they work fine with no crashes. so my recommendations are as follows.
- Latest iPad or iPhone (as they are generally faster)
- Latest iOS
- WiFi over 4G/3G
Windows 10 Mobile
- Lumia 950/XL
- Windows 10 Mobile (Insider Preview builds – fast track for latest update)
- Wifi over 4G/3G
- Latest Samsung/Google Phone
- More Ram the better
- Latest Android version (if the phone manufacturer ever releases updates….)
- Wifi over 4G/3G
Dynamics 365 Customisations – Form Objects
The last of the factors affecting performance can be the actual customisations developed as part of the solution built for the customer. Once a User has clicked on a record to open it, Dynamics 365 will use the available network to make a request for the record and download the form (for the requested entity record) and all child objects and the data contained on the form itself related to the record requested.
So the total request will be influenced by:
- The available Network Infrastructure (influenced by Latency and Bandwidth)
- The Servers performance and the structure of the data query
- The clients machine – making the request and the ability to process the downloaded data
- The customisations themselves
Microsoft have released a tool called the Performance Center (available in CRM 2013 and above I believe) which can be accessed in Chrome or IE (I find this works better than the original combination) by pressing the following key combination at the same time:
CTRL + SHIFT + ALT + Q
The tool allows you to visual all of the form components loading with their associated loading times. It will aid you in identifying the components which are having a negative impact on performance because they are taking a long time to load.
There are two very good blogs on how to use the tool here:
- Authoring Company: Cobalt Understanding the Microsoft Dynamics CRM Performance Center
- Authoring Company: Magnetism Solutions Microsoft Dynamics CRM – Performance Center / Form Load Analysis
Microsoft Resource: Optimize form performance
From a customisation perspective items below can collectively have a negative effect of Dynamics 365 form is loaded onto the clients device/machine:
- Form Layouts – such as collapsed tabs etc
- Client side automation
- Sub grids
- Web resources
When designing CRM Forms (UI) for each entity, a simplistic/minimalist design (less is more) is better than a bloated form with hundreds of fields, the more objects/controls on the form – the larger amount of data that can be displayed which will ultimately take longer to query and download to the clients machine. When designing forms with multiple tabs, consider having the tabs collapsed when a page is loaded (OnLoad) – objects contained in tabs would only be loaded when the tab is expanded (i.e. reducing the initial Page load time). The Tablet client restricts you to a maximum of 5 Tabs and 75 Fields being displayed on the device, with the mobile apps growing and using the same forms as the web client, this is a good design consideration to always take.
If Field Level Security is also implemented, then there are additional levels of access that needs to be queried by CRM and increasing the page load time to be able to query the data contained in those fields which will follow a similar hierarchy to Security Roles assigned/inherited with the User.
My recommendations are:
- Keep to less than 75 Fields on the form – Use Business Process Flows to facilitate displaying extra fields)
- Keep to 5 Tabs or Less
- Collapse all Tabs on form load except the main first Tab
- If considering Mobile design – keep to a single column format in Tabs and Section
- Increase your label widths to show all the labels (i.e. 175 or 200 pixels) which will stop Dynamics 365 to stop hiding some or all of the label
- Read Only controls are quicker at rendering than editable Fields
- Keep a track of which tabs and fields you have enabled for Mobile externally
Use the Mobile Preview (when customising the Form) in the Form Designer – click preview and select the correct mobile screen size. This will start to render the Mobile Client to display the Form you are customising to see what controls will exist on the Mobile form.
The following items also add additional overhead to page load times as they are a lot more complicated and require additional data to be downloaded.
- Social Pane
- Quick View forms
- Bing maps
- Timer controls
So if these items are not being used, just remove them.
Client side automation
Additionally – any unsupported customisations (mainly unsupported JS running on the form or interacting with the DOM) can negatively impact Page Load times and are not recommended.
Microsoft have recently announced the deprecation of the old 2011 end point and this will be removed after version 9.0 Important Changes – here, the older SOAP endpoint is being replaced with a faster and more efficient REST API (also known as the Web API); so when writing form scripts, utilise the new end point!
Sub grids on forms have a negative affect on the page load time as client will need to display and render additional related data based of the following:
- Users access through security
- View filter criteria
The data displayed could also feature lookup fields from other records, and the number of columns should be kept to a maximum of 5/6 before a major negative impact is felt.
When designing forms, Sub grids should be (recommended) placed in a Collapsed Tab by default until they are needed, when the user needs to read/interact with that data then they can expand the appropriate Tab. If the data is not required on the form, then keep access to that information controlled through the navigation related entities area, this will make that data available from the form but not on the form itself. Keep the number of columns to a minimum and preferably use columns which are sorted by an indexed (SQL) field.
Editable Grids are a new feature of Dynamics 365, and allow users to in-line edit related records from a parent record or list view. The functionality allows greater control of more data from a single location and will automatically add overheads to the network performance requesting more data.
Keeping the number of editable grids to a minimum if the related records displayed in the sub grid are there mainly for reference and should not be edited (I.e. Custom auditing, market sectors etc.)
Forms can have Web Resources embedded into them which can be used to display custom content (i.e. images, html pages etc.). These also increase Page Load times – consider putting these into collapsed tabs also and whether they should be rendered on a mobile client or not.
I hope this blog helps a few people with their Dynamics 365 implementations and identifying potential performance issues with your Users.
Thanks for reading,