To customise or not to customise, that isn’t the question

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:

TermExamples of what the term means
ConfigurationSettings within the D365 environment
Items which can not be included in a solution
Reference data
CustomisationPretty much anything that can be included within a solution excluding code.
ExtendingCoded web resources, JavaScript, html etc
Power Automate
Custom workflow steps
DevelopingAll other plugins.
Stand alone applications which interact with D365/PP
That Queer 365 Guys Model D365 Hierarchy of Change

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.

2 thoughts on “To customise or not to customise, that isn’t the question

  1. 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.

    Like

    1. 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.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: