One of the most common questions I get from IT managers in Greece and the UK isn’t about complex coding. It’s about simple governance: “Grigorios, we see a new extension in the list. Do we know who deployed it and when?”
In a busy environment with multiple partners or internal devs, it’s easy to lose track. Whether you are in the Cloud or On-Prem, the system does keep a trail, but you have to know exactly where to dig. After 15 years on Business Central and NAV (and 30 in ERP overall), here is my practical checklist for tracking these changes.
How I Track Deployments in the Cloud (SaaS)

In Business Central SaaS, the Extension Management page is usually the first stop for most people. It’s great for seeing the what and the when (install date), but for some reason, Microsoft didn’t include the “Who” in that view.
To get the full picture, you need to step outside of the BC client for a moment:
The Admin Center: Head over to the Business Central Admin Center and look at the Operations tab for your environment. This is perfect for seeing a clean timeline of when apps were moved into production.
The Audit Trail: If you need the actual user name, you’ll need to check the Microsoft 365 Audit Logs. Look for the activity “Added Business Central App”. This is the most reliable way to see which admin account triggered the installation. It’s a bit of an extra step, but it gives you the definitive answer.
If You’re Still Running on Your Own Servers (On-Premise)
If you’re running Business Central on your own hardware, you have much more direct visibility because you can go straight to the SQL database.
I usually don’t even bother with the UI for this. I run a quick query on the [NAV App Published App] table. There is a column called [Published By] that tells you exactly who uploaded the package. If you prefer logs over SQL, the Event Viewer on the service tier is your best friend. Just filter for “App Install” events and you’ll find the timestamp and user identity right there. It’s a more direct route and it never lies.
What Years in the Field Have Taught Me About Governance
If there is one thing I’ve learned in this game, it’s that good documentation beats a good audit log every time.
Even though the system tracks these things, I always encourage my clients to keep a simple “Deployment Log”, even if it’s just a shared DevOps board or a simple internal ticket system. It makes life so much easier when you can see why an app was installed, not just who did it.
Also, it’s worth reviewing your “Super” user permissions once in a while. In my experience, the fewer people who have the right to install extensions, the cleaner the system stays over time.
If you’re trying to clean up your extension list or you’re not sure where a specific app came from, feel free to reach out. I’ve walked through these logs with many teams and I’m always happy to help you get your environment back under control.

Director and Founder of GMSOFT, a Microsoft Dynamics partner serving the UK, Greece, and Italy. Microsoft Dynamics 365 Community Super User, Season 1 2026 — recognised for top-tier community contribution on Business Central manufacturing topics. Independent BC consultant with 15 years on Business Central and NAV (and 30 in ERP overall). Founder of two BC user groups: Business Central Greece on LinkedIn and Dynamics Business Central User Group Greece (Microsoft Community). Publisher of 3 apps on Microsoft AppSource (ABC Classification Manager, Vendor Dispute, BOM Architect) and open-source AL on GitHub (GmsoftLtd).
Discover more from Inside Business Central
Subscribe to get the latest posts sent to your email.
