So we had decided to extend one of our add-on modules. And as it had been measured on the short side we had to apply for an extension of the number of objects. Simple as that … it seemed.
So how to do that? PartnerSource surely would be of help, we thought. So we typed add-on extension. Nope. Add-on registration, bingo!
One of the two top hits did lead us to Microsoft Dynamics NAV Add-On Registration page which contains good info on the whole process of registering your add-on. Yes, I even pushed the thump-up.
The heart of this page (and the process) are these two documents:
- WW Microsoft Dynamics NAV Add-On Process Guidelines External
- WW Microsoft Dynamics NAV Add-On Request Form
Self-explanatory titles, but still a lot to read bearing in mind that we only needed to extend the number of objects. Just have a look at the table of contents. [:^)]
Well, it makes sense altogether when you start with an add-on first time. The spooky things to us were the section 6 and 7. Well actually not the sections as such but executing on them. And here is where the title of this blog post comes in view. It felt like being sent from one counter to the other, which, as matter of fact, were manned by the same MSFT.
First you need to apply for the object range (extension) uploading your request form on a Call Logging Tool (CLT) incident. This ‘… may take up to 3 working days to complete this step’, as the guide says. Counter one!
Then you need to apply for the ‘creation of the Add-on Module‘, i.e. a module id will be assigned to the object range. Counter two!
Eventually we had to do this for a couple of add-on’s and I am still astonished by this. OK, only two counters, that’s still one too much. For the extension we have two known’s, being the module id and the number of objects (to be added), and one unknown, being the number range. Can’t this be handled in one request?