To code or not to code, that still isn’t the question.

Following on from last week’s blog where we discussed our Hierarchy of Change. I am looking to expand on this and look at the first use to put this to.

To recap, I defined four levels in the hierarchy of change:

  • Configuration
  • Customisation
  • Extending
  • Developing.

This week, I am also going to add in “3rd Party extensions”. You may have decided to use the levels I suggested, or you may have come up with your own. There’s no right or wrong answers other than there should be no more than six levels. However, I’m sure many of you will have pencilled in a yes or a no against each of your levels of change. There are some wrong answers here if you did this.

If you thought yes, that’s ok to every single level, then sorry, that’s a wrong answer.

If you thought no, we don’t do that here, to any of the levels that’s also a wrong answer I’m afraid.

Let me delve a bit deeper in to why this is the case, we will come back to the hierarchy of change shortly

That’s another fine mess you’ve got us into

I find that some people can’t wait to tell me with glee about an organisation whose Dynamics 365 (D365) environment was in a mess because it had been heavily customised. They’re often eager to provide the anecdote as support for a negative view of D365.

I smile politely and nod whilst thinking, don’t you mean it was in a mess because they let any person and their dog make changes to the system with no consideration of its effects, good practice or supportability?

I’ve seen a few systems which are pretty much pure out of the box as can be without a single piece of code. And they have been in a mess.

I’ve seen a few systems which have had developers all over them adding plugins and bolting things on here there and everywhere and they’ve been great.

OK that second statement might be an exaggeration, but it doesn’t have to be. Heavily customised is not the same as badly customised.

But why do D365 systems often end up in a bit of a mess? Well maybe it’s something to do with people’s perceptions towards it, both from a technical side, and the business side:

  • It easy enough for anyone to change, so anyone should
  • It’s not development so we will let the business look after it all on their own
  • We will approach it exactly the same as any other development.
  • It’s just a tool to help develop quicker.

Yes, some of these may seem a bit rude but hopefully it will help people sit up and listen. However, once again us D365 evangelists are sometimes our own worse enemies.

Trust me, I’m a D365 Specialist

How many times have we told architects and department heads “oh it doesn’t work that way”? For those of you who are end users, how many times have you heard this? And how many of those times have we been able to provide a clear description of the issue and point to documentation of how it is addressed within D365?

If you are anything like me the answer to the first question is quite high, and the answer to the last question is rather low. Given that, how can anyone differentiate between someone who knows their stuff, and someone that is blagging? You are effectively saying, ignore all you know and trust me.

This is one of the motivations behind these blogs, to provide that back up material for the quirks of D365 and the Power Platform(PP) (my next installment will look at more reasons for this series). But for now, the message is, we need to be shouting good practice from the get go, and explain what good looks like in the world of D365 and PP. And what better place to start than good, effective governance.

Governance isn’t a two-option set

Governance and effective governance are different things.  Whilst it’s a rabbit hole I don’t want to go down in this blog hopefully you can trust me (yes I’m a D365 Specialist) when I say:

Following a policy or protocol ensuring all the steps have been covered to come to a yes/no decision is governance. Knowing the context of the policy or protocol you are following and knowing the right questions to ask to come to a decision which has conditions attached is effective governance.

So, where does this leave us, and what does this have to do with the Hierarchy of Change?

Lets go back to my list

  • Configuration
  • Customisation
  • Extending
  • 3rd Party Extensions
  • Developing.

Now we have defined these levels, we can decide which type of changes our business wants to utilise. So for you who have pencilled in yes and no against each level, let’s look again.

Whilst not an exact science, we can see from top to bottom, there is an increasing degree of effort required, which may mean an increased cost and risk. This is why a blanket yes to every type of change is a bad idea, however, there is also an increasing amount of flexibility which can be offered as we go through the levels so maybe ruling stuff out isn’t always the best idea either, no matter how well intended.

This is about effective governance and controls. Whether it is an in-house support team, or a consultancy delivering a new system, it allows you to be clear which type of change can be utilised freely, and which ones need to have explicit approval.

Once again, I am going to get you started so here is That Queer 365 Guys Hierarchy of Change and Control….

Using a fairly simple imaginary structure of front-line support, D365 support and Technical Design Authority (TDA) I can envision a basic set of controls and governance structure below.

LevelWho byControls
ConfigurationFront line supportMust be documented in change log
CustomisationD365 teamTesting signed off and release notes approved by TDA prior to release.
ExtendingD365 teamAs above, but each extension must be explicitly called out in test plans and release notes.
3rd Party ExtensionsD365 to identify and prepare documentation for it to be approvedTDA approval required
Developing TDA to assess before any development commences
That Queer 365 Guys Hierarchy of Change and Control

One thing to note, is that the controls become slightly more burdensome as we go down each level. This is intentional. It forms what is known as an administrative filter (also known as a bureaucratic filter) It should help encourage your team to find solutions which remain as close to vanilla as possible without tying their hands.

It’s really that simple – almost

This is the starting point. Obviously, every organisation is different. In a small organisation your TDA might just be your IT manager. In a consultancy the TDA will likely be the client. It’s basically a slimmed down and tweaked RACI chart

You may want to add exceptions as well. For example, any new relationships to the contact entity needs approval of a senior team member. You might suggest that a formal discussion is held (and documented) amongst the D365 specialists for any new entity.

To code or not to code – now it’s the question

So now I am looking specifically at the final level, rather than the odd line of JavaScript. The simple approach should be never-say-never. Yes, you can make it as burdensome and as unlikely to be approved as you want, but you need that path just in case. There will always be that one use case that needs that extra bit which D365 cannot offer.

You need to ensure there is a path to get this coding approved. It protects against someone going rogue, it also encourages collaboration. If a D365 Specialist can only see a solution by developing some standalone functionality, taking it to TDA means they get chance to suggest alternatives (that’s right, even when they say no, they should be giving options) or allow you to tap in to support from the wider business. It also means if it is an absolute must have for the business, you can take it to TDA, and then let the business and TDA have the discussions between themselves whilst you get on with other work.

Homework time

Yup once again there is some homework to do.

Think about your hierarchy of change, and think about what level of controls you would like around it. Think about your as-is, and think about what would be a better way. Even if you have free reign, it’s useful to ensure there is some oversight. If you think your current set up is restrictive, what would you like more freedom to be able to do you? If you are an end user about to embark on a project with a consultancy, think about what changes you want them to speak to you directly about.

Copy mine from above if you like – let me know how you get on.

Now, here’s the interesting bit. Once you have it. Take it to your TDA, or whoever fills that role, and get them to approve it. Not just a quick nod. Walk them through what the levels mean, explain what you mean by change, and show them that you know what you are talking about. Give them confidence that whilst D365 may have its quirks, it also has its own good practices and they are to the same standard as any other software and project good practices.

Once you have it agreed, then why don’t you publish it let people know on the forums, share amongst your networks. Let’s make sure when people are new to D365 and PP, they can search the internet and D365 specific good practice will show up.

Please like follow and comment. My next instalment will be slightly different and I will be looking at why we should develop good practice, expanding on my introduction.

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.


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.

Why Good Practice?

So here’s a quick intro to myself and why I decide to start blogging.

I came into the world of IT and computing fairly recently, in fact, my move to work professionally in technology was through Dynamics 365(D365) or CRM as it was then known.

All sorts of things were new to me, project management, development approaches, and yes, good practice. Most of the approaches and methods I learned about were predicated on one of two scenarios: fully bespoke development, or commercial off the shelf software. Very few approaches and methods seemed to fit that well with a low code solution. When I continually asked why we were taking a given approach, it wasn’t because I was being naive or didn’t “get it”. As I was coming to D365 without having previously used these approaches, it was a bit clearer for me to see when maybe they weren’t working so well

As I have gone on in my career, I have found three constants. Firstly, those of us who work with D365 day in, day out are well aware there are ways to use the system that just make our lives easier, and when asked would almost always reply “of course, that’s just good practice”. Secondly, that when working with people who have not worked with D365 before, they don’t always want to take our word for it, and prefer to go with documented approaches, regardless of how well they fit a low code solution. The third constant links these together, as a community we aren’t the best at publicly documenting good practices.

Yes there’s lots of information and tutorials on how use different aspects of the system, and how to achieve specific outcomes. In true Microsoft style, there’s normally a dozen ways to meet any given requirement. However, for each given approach, there is little discussion about whether we should use it or not.

So here we are, this blog is my attempt to help spread the word about good practice. Whilst some of it may come across as quite prescriptive, most will be around how you can develop good practice in your own teams, and what things you should consider and have in place.

I will do a more through introduction in the future, but I didn’t want to merge my introduction with my first post, but neither did I want my blog to appear with little or no context.

Future topics may include:

  • Difference between Must and Must (Also known as the difference between Should and Should
  • Managing Environments and Releases
  • Putting it back to out of the box

Given that everything I know I learnt from Star Trek, my blog will be starting with a two-parter Part 1: To customise or not to customise, that isn’t the question will be out on Wednesday.

%d bloggers like this: