Never shy away from a catchy title of your blog right?
So enough said about why we need Design Patterns AKA Best Practices for Per Tenant Extensions, let’s dive into my suggestions.
Rule #1 – As few as possible
If you implement Business Central you should have a close fit to your business requirements. The times when we hacked the base app into anything are gone except for a few rusty brown partners that are allowed to still do so.
On top of the Base App you mix and match AppSource solutions. Typically 1 vertical solution and a few horizontal ones. Like for example PrintVis with ForNAV and Continia as something that everyone would understand.
What you then do with your “Per Tenant Extensions” is essentially defining exceptions on metadata level with a few scripts that you want to execute whenever something happens in the system. “Per Tenant Extensions” are not massive blocks of vertical business processes except in few cases but but as a general rule of thumb.
You may have small processes in your PTE that we would call “features”. In many cases they relate to an interface with this and that or creating an excel sheet that goes somewhere in the organization that is fairly unique to a company. You may however reuse these features in other implementations. Not exactly the same but, you know, as inspiration for starting on the next adventure.
The Anti-Pattern – Many Small Per Tenant Extensions
Design Patterns are often easier to explain by telling how not to do things and/or what can go wrong if you don’t follow them.
The biggest problem with having many smaller Per Tenant Extensions is the lack of overview and manageability. I’ve seen first hand situations where source code got lost, different programming styles were applied, objects ID’s were difficult to manage etcetera etcetera. I am sure you can write something in the comments that also illustrates what can go wrong if you start defining too many PTE’s.
Another challenge that should probably not be a challenge but still is, is performance when extending tables in the Base App or in our case PrintVis multiple times.
Even though Microsoft has done a lot to improve the behaviour, it is still not completely “nice” to have all these extensions and in case of a PTE there is a fair chance you want all “your” fields added to list pages anyway right?
But what about reusability?
This I agree is a problem with a big PTE and I promise I will get back to you on that and we’ll fix it in my next blog or the one after that.
I thought you would never ask. What are the exceptions? There is IMHO only one exception which depends on the Service Level Agreement you have with your customer.
Many customers with a larger internal IT team want to do their “own stuff”. Especially reports.
Off course you can make an agreement with your customer that they can get access to the PTE, but only change report objects, not anything else. This may work to some extent but it ships a bit easier if you create a dedicated “Report Pack” extension that is the responsibility of the customer.
I agree, it is debatable and probably after reading the rest of the Best Practices series you agree that we may as well include the reports in the big “PTE”.
Also, if you use ForNAV, 99.5% of all report changes can be done WITHOUT per tenant extensions so it becomes a non-issue all together.
Organizing the Per Tenant Extension
That is a story for another day, most likely wednesday or thursday as tomorrow I have other plans.
What do you think? Please leave your comments below.