Future Proofing your Dynamics 365 implementation and Configuration (Part 1 – The licensing question)

Microsoft Dynamics 365 Customer Engagement is an incredibly versatile platform that can be configured with relative ease. This is both a good and bad thing because often solutions that are implemented descend into configuration anarchy. Yes, it sounds as bad and it is. Imagine a deployment with hundreds of entities, attributes and solutions that are irrelevant or are there for no particular reason. On the other hand, what about loads of old ISV solutions that aren’t being used anymore. As fans of Dynamics 365, I can guarantee that most of us have seen this. 

So how does one future proof their implementation? I appreciate the fact that there will be loads of opinions on this matter and there are hundreds of things one could do to manage this process from a business and technical point of view.  

One of the big questions during any implementation is whether to utilise what is available out the box or whether to create custom entities and attributes. This is generally based on the scenario and the customer’s requirements. Personally, I prefer to use what is already available as much as possible as there is a load of functionality that you may need to rebuild using workflows and plugins if you go the custom route. IN ADDITION, when Microsoft release updates / upgrades, I know the functionality in my solution will be upgraded correctly and is in line with Microsoft projected functional roadmap. That isn’t to say that Microsoft don’t deprecate functionality. They definitely do! 

Now, here is the thing: The licensing model limits us or controls what you can and can’t do as far as the addition of custom entities relevant to the existing functionality. YOU MAY NOT REPLICATE THE FUNCTIONALITY OF STANDARD ENTITIES IN DYNAMICS 365 WITH CUSTOM ENTITIES. If the standard entity is replicated then the user must be licensed appropriately for that standard functionality. This is available in the Licensing and Pricing guide on page 17. THEREFORE, in short… you can create your own “Case” entity, sure… However, you will then need to purchase the Dynamics 365 for Customer Services license for users that will be accessing this entity. This is because it replicates the current and standard case management functionality. 

This makes absolute sense. Information on the enterprise-licensing model can be found here in appendix B.

This is one of the first documents I generally consult during solution design. Microsoft suggest that configurators utilise what’s available within the standard Dynamics 365 platform so that when core functionality is added to the platform on top of the standard entity set or functional area (marketing, Sales, Service, PSA & Field Service), customers have access to this without having to add additional configuration. As an example, when the entitlements functionality was added to the services module, it linked to the standard case entity and functionality as a standard. Companies that had built their own case functionality had to either move to the standard case management functionality or configure a link to the entitlements. 

A second example that I have come across before, which required configuration and was considered future proof was where a customer had several case types, each of which required a large amount of data capture. Instead of adding hundreds of fields to the case form, the case was simply used as the header record and a set of custom entities was created for each of the categories. The core case functionality, such as routing and email-to-case was used and the configuration flexibility of the platform was used to apply a huge level of personalisation from an incident management point of view.  

In summary, part of future proofing your configuration is to bear in mind what Microsoft offer as out the box functionality, as well as what the licensing model allows you to do and not to do. Often, this involves an honest and transparent conversation with your customer, which will enable you the ability to educate them in what, is required to implement a robust, performant solution that is as future proof as you can make it. In the next post I will be talking about the Dynamics 365 roadmap and how you can prepare your solution for what's coming.