Every time I hear those dreaded words “we don’t want any customisations” I sigh, and begin wondering how much of a headache this project will be. I wonder what your response is? Sometimes what I want to say is:
“I’m sorry, but you obviously don’t know what you are talking about”
However, as I’m trying hard to be less annoying, from now on my response will be:
“I’m sorry, can you clarify what you mean by customisation?”
We may sound rude or arrogant trying to get someone to answer this question, but unless we start calling it out, we will always be in this situation. And there lies the root of the problem, and the focus of the first instalment of this blog. What do we mean by customisation?
Let’s be clear, we’re not always clear
We don’t always have a common language in our community, and where we do, we are not always the best at communicating that. Those outside of the Dynamics 365(D365) and Power Platform(PP) worlds often have minimal experience of our worlds. It is sometimes viewed as an off-the-shelf application which just needs a corporate colour scheme added.
As D365/PP specialists we need to start being upfront about different ways an environment can be changed, and communicating that in a simple way. Then we can stop everything getting lumped in with the term ‘Customisation’. We are then much better equipped to challenge people’s perceptions of customisation.
But how do we do this? Are we not just being pedantic? Maybe, but there are clues out there already.
Previous courses and certifications talked about customisation and configuration, these focused almost exclusively on the non-coded aspects of the application. In fact, if you look inside a solution zip file you will see a folder ‘customizations’.
Reference is also made to ‘extending’ the platform in various documentation and courses aimed at developers.
Hierarchy of Change
To help you out, I’ve pulled this information together in a matrix to group types of changes we make to a D365 environment. I have used this successfully now on a few projects. So to get you started here’s That Queer 365 Guys’ D365 Hierarchy of Change:
| Term | Examples of what the term means |
|---|---|
| Configuration | Settings within the D365 environment Items which can not be included in a solution Reference data |
| Customisation | Pretty much anything that can be included within a solution excluding code. |
| Extending | Coded web resources, JavaScript, html etc Power Automate Custom workflow steps |
| Developing | All other plugins. Stand alone applications which interact with D365/PP |
After breaking it down like this, “We don’t want any customisations” seems a redundant statement. Unfortunately, this is where people may start moving the goal posts. Don’t worry, I have the response to two of the moved goal posts all ready for you
“I mean no heavy customisations”
Ask them to list out explicitly what qualifies as heavy. In the mean time you can be doing your homework (did I mention I’m giving you homework?) and eagerly await the next instalment of this blog.
“I mean no coding”
A-ha! Now we are getting somewhere, a few upcoming events have the strap line “To code or not to code” so looks like we still have a bit of a discussion, but now we have a better idea of boundaries.
Tell them that is a better statement, and that you will get back to them. File the comment away whilst doing your homework and awaiting the next instalment.
Homework
This blog isn’t about telling you what you must do, but about giving you things to prepare for yourself. So on that note, please speak with your colleagues and draw up your own version of a D365 Hierarchy of Change. If you want to copy and paste my suggestion, feel free to do so, but also please feel free to tweak it.
You may wish to drop a term, or you may wish to add a couple, but don’t add too many more, its about giving broad categories rather than fine details; six levels should be the maximum. In the next instalment of this blog we will start fleshing it out more.
Maybe you want to change the terms used slightly. Or change them completely to something like level 1, level 2 etc. That’s fine, as long as you have a common understanding in your organisation or project about what kind of changes you are referring to.
You may also wish to change what each term covers. Maybe you class Power Automate as a customisation, or perhaps html web resources as development?
What ever you do, please make sure you document it, and share it with others although you may wish to wait till part 2 before publishing too widely.
Finally, please comment on this blog, share it with your colleagues, and let me know how you get on.
Please drop on by next week for the next installment: To code or not to code, that still isn’t the question.
That Queer 365 Guy 
Interesting. I like the hierarchy, with Complexity and Cost increasing as one reads down the hierarchy. In the context of cloud systems, organisations want to minimise the need to re-apply changes to keep in step with the cloud supplier’s release/update cycle. And want to follow best practice and international norms and work flows; less of ‘but our org is special and we really do need to do things differently!’ I see Configuration as the minimum – it’s implementing your org’s Business Rules in the off-the-shelf system, which for eg will translate into specific menu options, and approvals steps when processing a purchase order, or booking time-off leave. Customisation is changing the process and workflow. Extending may be adding functionality through APIs or coupling with other modules, or 3rd party software.
Interested to read the series of blogs you have planned.
LikeLike
Thanks for your comment Ash. My next blog, which is out later today, is going to build on this – touching on the point you mentioned about cost and complexity – to put in appropriate controls/approvals. There are a few other areas which can use this as well – eg booking test resource.
LikeLike