It's interesting just how much the Dynamics CRM platform has changed over the years, specifically in the area of data visualisation. Microsoft has progressively incorporated additional options for us, giving system customisers and developers a broader set of tools to deliver great content-aware visualisations.
To name but a few, these options include the ability to colour entities and business process flows; Native Dashboards; and integrated visualisations surfacing in PowerBI. Additionally, the ability to modify grid views and incorporate visual queues to a data set, insights and many others are included in the current platform offering.
If we explored all of these tools, we would be here all day. Instead, let's focus on one specific feature that was made available since the December 2016 update for Dynamics 365. While only a relatively new feature, it's one I feel has great potential where adopted and used well, and become a key consideration when putting together a Dynamics 365 solution. As a bonus, it's also really cool!
The feature I refer to is the ability to add visual web resource to a data view within your Dynamics environment. What this gives us is a method to introduce a visual key to what was previously just a raw value in a grid column.
By attaching a web resource and a JavaScript library to control what icon is displayed based on values within the data row, there is a considerable amount of benefit to a someone who is interacting with the data on a daily basis.
Once configured, an example can look like this:
This is such a cool feature, and the aim of this post is to dive right in to this functionality to highlight what you can deliver and its limitations, explain how this feature is implemented within the platform based on exploratory testing and also cover some basics of data visualisation and the real use cases for implementing it.
I’ll go into more detail on how to set up and configure this future at the end of the post. If you want instructions to set this up you are welcome to skip to the video further down which goes through the implementation process end to end.
It’s ok, I won't mind, but hopefully, you’ll stay for the rest of the post too!
Before we dive under the hood and look at this from a technical perspective, it is important to consider the potential impact of this feature and how best to use it to your advantage.
For me, the key driver here is the ability to interpret a large dataset, a view in this case, at a glance and build a story from it to make informed decisions.
This is basic data visualisation but there are countless ways of visualising data in Dynamics CRM, so what makes this different? Well, this feature is right at the front line of the system in an area of the product which has a high user interaction and a daily footprint.
Using this feature well means that our setup is thoughtful and specifically focuses on our ability to focus on highlighted data so that we reduce the time taken to understand the data we are presented with.
So if that’s the driver and a key use case for this feature, then think carefully on how we should be using it and when we customise our Dynamics CRM environments.
Views – Under the hood
So how do static views work in CRM? Well, there’s a number of components which control how these render and the data that they represent in the application, But there are two very important components that control a View, these are XML data items called:
- FetchXml
- LayoutXml
They’re important because these are what we interact with using the out of box customisation tools or via the Software Development Kit (SDK) when creating a new SavedQuery (A View).
If you’ve ever played around with custom filtered lookup with the Client side SDK, you will have interacted with both of these XML configurations. FetchXML may also be familiar to you already if you’ve ever used FetchExpressions to Query data using the SDK, or used the FetchXML builder found in the XRMToolbox.
FetchXML
This defines your request to the database (your “query for data”) by specifying which Entity Set you would like to query (eg opportunity), and the fields you would like to be made available on each entity that the query returns in its results. It controls how the data is filtered, and how you want that data to be sorted.
LayoutXML
This controls how the grid represents itself and how the view “looks” in the application. It’s specific to views of data, however, the FetchXml is fairly reused within the platform.
Even if this seems a little alien to you at the moment, It is likely that you’ve interacted with these XML settings even if you were not fully aware of it.
If you’ve ever configured a System view, then these two areas are directly affected by the choices you make in view designer.
Below is an example of this, where I’ve separated the controls to highlight which configuration area(s) they interact with.
So actions through the view designer will have a direct impact with the XML configuration properties of the Saved Query once the save button is clicked.
For example, Moving the columns left or right in the designer will adjust the cell sequence in the Layout XML.
As captured below:
Or, Editing the filter Criteria, to include more view filter options, will affect the Filter elements in the Fetch XML.
Editing Filter Criteria:
Want more information on the end-to-end implementation process? Watch my guide: