Future Proofing your Implementation and Configuration – Part 3 – The Configuration Question
In part 2 of this 3 post series I spoke about the Microsoft and how you are able to keep up to date with what is being released, so that you don’t end up building something into your Dynamics 365 implementation that is going to be added in a next release. In this post, I am going to talk about why it is important to carefully consider the use of custom functionality versus the use of out-the-box functionality when implementing and configuring Dynamics 365 Customer Engagement.
Why would we want to make our implementation of Dynamics 365 future proof? Well, there are loads of reasons.
- So that upgrades are smoother and less painful.
- So that customers can leverage other parts of the solution to support their business.
- So that Dynamics can be grown from both a functional and business point of view.
Essentially, Dynamics is used to solve more problems, which then increases user consumption and adoption.
So, I guess the million-dollar question is “Should we configure this or should we use what’s available out the box”? I have been working with Dynamics 365 CE (CRM) since version 3 and a lot of the time, in the earlier versions, we needed to configure stuff from scratch. There was a load of great functionality there already, but the previous versions were nowhere near where Dynamics 365 is today.
Now, for all my developer friends out there, I am not saying that there is anything wrong with coding at all. What I am saying is that the role of the developer has simply changed from when the previous versions of Dynamics were released. Before, functional consultants like myself were expected to code and write plugins, and if you couldn’t then you needed a developer with you. Now, this may not be the case. There is so much one can achieve with what is available out the box in Dynamics 365 that developers are focusing more on REALLY extending what Dynamics 365 can do.
So, back to my question….. Do we build it or do we use what is already available? Well, in my opinion, the answer is relatively simple. We use what is already available and extend through configuration, customisation and ISV solutions where the functionality we require is lacking. This approach really is in line with the Microsoft future proof strategy where the current functionality utilised within the Dynamics 365 CE framework is supported. Caveat: Yes, Microsoft do often deprecate functionality that is not widely utilised (Such as contracts).
Some time back I had a scenario where it was suggested to me that I did not utilise the standard Case entity and I was told that it would be better to recreate this functionality in a custom entity because it gave me more flexibility and freedom to do what I wanted. (Multiplexing rules aside) I didn’t agree with this. Why? Well, to recreate the functionality that existed in the standard case entity would have taken me more than 3 times the amount of time that it would have taken me to just do some basic config to support the main case entity that is already available in D365 CE. I would have to do all sorts of crazy stuff around routing rules, SLAS, Entitlements, Case Resolutions, Case Hierarchy and much more. It seemed that the right thing to do would be to supplement the case entity with some related metadata entities that enabled the user to lookup to various sub entities. This worked well because it also gave the users the power to maintain their own lookups.
The other thing that we thought of was that we couldn’t ad hundreds of fields to the case form. This would make maintenance and business rules a logistical nightmare. We ended up creating several sub entities for each case category and then just associated the sub entity to the case. This way the core case management functionality was utilised but not drowned with attributes. This also made upgrades MUCH easier.
Scenario 2 was a little different where I wanted to utilise the standard Contract & Contract lines entity in Dynamics 365 CE. I found that the functionality that I wanted couldn’t be achieved through utilising this entity set. One thing that really stood out was I couldn’t enable a contract to be associated to the Business Process Flow functionality, which was pretty important as far as the “Agreement – Contract” process was concerned. I actually ended up creating a custom set of entities and only ended up replicating a very small amount of the current contract functionality.
There are hundreds of examples of this type of thing that I could bring up at any one given point. One of the most talked about scenarios at the moment is “Will Custom Controls (CCF) replace web resources”. In many cases, yes! Check out this video for a bit more information.
Essentially the moral of the story here is that the requirement to configure the solution versus utilise what’s out the box is entirely scenario based. What I’ve found is that the more I utilise out the box functionality within Dynamics, the ore future proof it is. HOWEVER, this needs to be done in such a way that you don’t completely overuse the standard functionality to a point that it can’t be leveraged across the rest of the solution. The example in scenario 1 with the case management is a perfect example of using what’s out the box, but knowing how to supplement with config.
When implementing Dynamics you need to be a bit like the precogs from the movie Minority Report. You need to look into the future and try to understand how your customer may grow as well as how the solution may grow in order to be more future proof.