It seems I’ve been experiencing strange consequences of giving up on my MVP renewal, which is that I now don’t need to worry about sticking to some (real or imaginary) rules, I don’t even need to write anything here, but, somehow, that together just unlocks some of the topics I probably did not dare to write about before.
Specifically, what’s the actual difference between supported and unsupported customizations? This mostly applies to the DOM model manipulations, since there are not a lot of other things we can do there which would not be supported (as in, if you can’t do something with a plugin, you just can’t. But you can do a lot of things with Javascript, and, as soon as you start accessing HTML elements directly, that’s where the “unsupported” stuff begins).
Officially, Microsoft is not responsible for anything that breaks in your application because of the unsupported changes. This may happen, for instance, because an HTML element that used to show up on the page is not there anymore (in those cases where Microsoft will decide to change something), and, given how much you can do in the supported way using client-side Xrm, it seems generally better to avoid unsupported customizations.
However, let’s dig a little deeper:
- Personally, I had examples of the official support cases where something would be expected to work, but it would not, and, since the issue might be considered to be “low priority”, there would be no immediate (or even near-term) fix. That does not happen often, but that does happen
- With the Canvas Apps, it’s recommended to update them periodically so they pick up the latest features (to bring those Canvas Apps ” up to date”)
- With the model-driven apps, there are new features coming out all the time as well, user interface is getting updated, etc, so you definitely can’t leave them be there for years without having someone on your team to keep an eye on them
Where I’m heading with that is: whether you go with supported customizations only, or whether you add some unsupported ones, ultimately you do need someone to keep supporting your Power Platform applications in production no matter what.
Then the risks of having unsupported customizations in there may need to be looked at differently:
- Can the users live with those customizations stopping to work? At least temporarily, till someone figures out updated HTML structure and makes required changes in the customizations
- Will there be someone around with enough technical knowledge to possibly look into such issues? On that note, it’s not unusual to see projects released into production without adequate knowledge transfer from the dev team to the support team, and that’s just based on the false premise that everything will keep working forever (see above why not), so the question of having someone with adequate knowledge is rhetorical. You have to have someone there, otherwise you’ll just be taking on a huge risk, and supported vs unsupported will not be the problem to deal with
- Sometimes, what is “supported” on the surface, is not quite as supported if you dig deeper. This is when we start talking about the architecture and design, since, for example, what if you write a very chatty plugin that’s making thousands of calls in a loop (instead of using one fetch), and, while doing so, it’s consuming all the API calls a user has for the day? It’s technically supported, but, ultimately, it’s going to cause even more problems than direct HTML access (which is why, in many cases, we would still hear “stick to the out of the box customizations” as long as the word “coding” comes up, to which I’d often say that Xrm framework is out of the box, too, and it’s there for a reason)
So, ultimately, there is no clear boundary between supported and unsupported. In some way there is, and that’s where Microsoft is clear on what they are going to support, but, even then, things can and do go wrong every now and then. What matters, in my opinion, is whether your organization has the means of supporting what’s needed to be supported, which usually means you need someone on your team to provide that support. And, of course, it also matters how often things break and how damaging those breaks can be.
Unfortunately, that’s a lot longer answer to the question of “what can we customize here”, compared to “just don’t go with anything that’s unsupported by Microsoft and you should be fine” 😊