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.
1.
So that upgrades are smoother and less painful.
2.
So that customers can leverage other parts of
the solution to support their business.
3.
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.
I remember spending hours trying to get past a problem
without using loads and loads of code. This is partially because I am no
developer. There was a huge reliance on form side scripting (pre-business
rules) where setting things like field visibility or business relevancy
required several lines of JavaScript, and this was incredibly Important because
the experience of the user was at stake. The reason we tried our best not to
code was because when the next release came out, there were always issues with
certain bits of code not being supported and not working.
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.
No comments:
Post a Comment