Brown's Notes

When working with Dynamics NAV ISV applications, you'll routinely be asked by vendors to expose NAV's SOAP service to the internet. This should make you feel uncomfortable. Thankfully, leveraging the Azure Active Directory Application Proxy makes this much more secure, and saves having to configure any additional infrastructure on-premise which may require thinking about DMZs and unruly firewall rules. A little background info... If you aren't familiar with Azure's App Proxy service, see my post about configuring it for general web applications here . It's a good introduction to it. This article goes on to assume that you have a functioning Azure AD App Proxy connector service running in your environment. I'll also make the assumption that you have a Dynamics NAV 2016 or newer service tier configured with an SSL certificate thumprint installed such that SSL can be enabled on the SOAP services. ...and A note on SSL...

Extensions for Dynamics NAV were released in NAV 2016, and were touted as a way to extrapolate all customizations out to an additional layer, leaving NAV's base code in tact and a nice, tidy and easy-to-upgrade platform. With the addition of events (which are fantastic), this sounded terrific and my development team and I were excited to get started with them. However, there are some serious limitations with extensions, and it's critical to be aware of them before starting down the road of heavy NAV development, as they can leave you with a tangled, virtually unmanageable mess if not kept in check with a clear plan of how best to employ them. The major one by far - and the subject of this article - is the poor design around field dependecies and customers' ability to make any changes to an extension "app" that any other app is dependent upon. In short, you won't be able to without first uninstalling any dependent app in orde