When you add actions to the item list and try to save the object, you will see this error. If you don’t use the North American database, you are lucky, because this error doesn’t happen in all localizations, only in the NA version – from what I have seen at least.
Why do you get this error, it didn’t happen in NAV 2016 or earlier? Is this a new bug? It actually is an old bug in the development environment or classic client. However, it’s not so much a bug, but a limitation of the client. The issue is that the client is a 32-bit client and has its limitations – in this case, it is the limit of the total metadata of a page. This means, once you reach this limit, you cannot add anything to the metadata of the page.
I brought this to Microsoft’s attention during the ACE program for 2017 and as of now, it still has not been fixed, which means that it is not an easy fix and you should not expect a fix. The good news is that the new compiler won’t have the same limitation, so you can add additional actions to the item list through an extension, at least. But this doesn’t really help for the normal customizations that you make for customers. So, what can we do to resolve this?
You could remove some actions from the list and then add yours. Does this make sense? If you make those modifications for a specific customer, you could probably remove the actions that are not needed, however, it is not the best way of solving this issue, since you will have issues when you want to merge cumulative updates in – either the actions are added back in or they, at least, will show up as additional changes and you have to take care of this during all upgrades going forward.
A better alternative would be that you remove languages from the system. For instance, a lot of customers only need English, so you could easily remove the ENC, ESM, and FRC language layers. Since this will remove the captions and tooltips for those languages, you will have plenty of space for the additional actions.
You can find information on how to remove languages at How To: Uninstall Language Modules. You can also export the specific objects as text and then use the Remove-NAVApplicationObjectLanguage PowerShell commandlet to remove the specified language(s) from the object. From a change management perspective, it makes sense to only remove the language from the objects that have the issue, at least, if this is for a specific customer.
What I really would like to see, however, is that Microsoft removes the languages from the objects all together and provides the language modules separately with some functionality to be able to download and install the language packs from within the application or at least via PowerShell. In my opinion, languages have nothing to do with the actual data structure, business logic, or the design of the user interface – they are just translations. The biggest benefit would be that we would have less changes in objects when Microsoft is fixing or changing languages, since those would not update the object, but the language file only. It could also mean that more objects would be the same in all localizations, since all localized databases could be shipped with English only.
We will see what the future brings, when the new development environment matures and maybe can eventually replace the current environment. But until then, we all will have to live with the limitations and have to find ways around them without causing too much additional effort.