In-client designer strikes back

The In-client designer is like the picture of Tacconi’s family in my aunt’s house: a simple reminder of the past. But without the dust. 

Originally, it was born to help C/AL developers to create page customization faster (layout only) and let them embrace the extensibility paradigm and be more productive at the same time.  

It was, and it is still, clearly stated that it must be used in test, development, or sandbox playground environments, just to make the development faster. That’s it. Period.

I know that you do not trust me. Then trust the official docs:

Using Designer – Business Central | Microsoft Learn

Today, after 10+ releases and more than 5 years, I believe that AL developers are not using (if they ever did) the in-client designer to generate page customization objects. Correct me if I am wrong.

Moreover, with the advent of 2023 Wave 2 and

1. improvements made in the personalization and profile customization area (such as the long-debated AllowInCustomization property)
2. the exponential productivity features added in Visual Studio Code (advanced snippets, GitHub Copilot, etc.)
3. applied DevOps to track extension lifecycle

I believe that the in-client designer option enablement has (much) more disadvantages than advantages and it is really time to turn this feature completely OFF, for good (overall in on-premises environments).

The message that I am trying to transmit with this post is that the in-client designer, left as an option to be turned on/off on-premises in the navsettings.json file, could be easily misused and abused. And yes, I could still witness on-premises production environments with this switch turned on. Mostly because:

1. Personalization and page customization were quite poor, initially, and salesperson or consultant used to demo the designer as the solution to fix the gap between the personalization capabilities within Windows Client and Web Client.
2. The “Designer” key is not present in the navsettings.json template file. Hence it falls back to the default behavior. Guess what it is the default behavior? True (darn…). This means that if you want to turn this off, you must instrument your deployment and upgrade processes to always check if that key exists in the navsettings.json file. If it does not exist, then add it and set that to false.  

The price to pay to have this enabled in production is to completely lose the control of your extension deployment (say goodbye to professional DevOps) and you might end up in situations like the one shown below:

With a lot of warnings when running “Personalized Pages” because of missing anchors for personalization metadata.

And that typically comes with users complaining that are not finding anymore their personalized fields or columns anywhere right after an upgrade. Finally, try thinking about moving these environments in the cloud: you will be forced to analyze and transform all these freaky dev extensions into a real PTE app.

In shorts: we live in 2023, there is no longer need to enable the in-client designer. And if you do not trust me nor the official docs, you surely would trust Waldo:

Business Central Modern Client: Remove the designer button (waldo.be)