Summary

Running Business Central Telemetry without proper setup is like flying a plane with no instruments — you might stay in the air, but you’ll have no idea when something’s about to fail. In this episode, I explain why telemetry is the single most important tool you’re not using, and how it can transform troubleshooting from guesswork into clear, data-driven action.

We’ll cover how to hook telemetry into Azure Application Insights, why one small detail (the Application ID) trips up so many admins, and how Power BI turns telemetry into dashboards you can actually use.

Just as important, I’ll clear up a common myth: telemetry doesn’t expose invoice or customer data. It’s strictly about system health and performance. By the end of this episode, you’ll understand what telemetry really is, how to enable it, and why flying blind without it is a risk no team should take.

What You’ll Learn

* Why telemetry is like your system’s flight instruments

* How to connect Business Central telemetry to Azure Application Insights

* Which Power BI apps to install and how to use them effectively

* The critical difference between Application ID and Instrumentation Key

* How to switch from sample dashboards to live telemetry data with lookback & refresh settings

* Patterns that reveal spikes, deadlocks, and extension issues before users raise tickets

Full Transcript

Imagine rolling a D20 every morning just to see if Business Central will behave. No telemetry? That’s like rolling blindfolded. Quick side note—hit subscribe if you want regular, no‑nonsense admin walkthroughs like this one. It keeps you from wandering alone in the dungeon.

Here’s the deal: I’ll show you how to connect the Power BI telemetry app to Azure Application Insights, and why one field—the Application ID—trips more admins than any boss fight. To run full live reports, you’ll need an Application Insights resource in Azure and a Power BI Pro license.

Telemetry only captures behavior signals like sessions, errors, and performance—not customer invoice data. It’s privacy‑by‑design, meant for system health, not business secrets. Without it, you’re stumbling in the dark.

So what happens when you try to run without that visibility? Think no mini‑map, no enemy markers, and no clear path forward.

The Hidden Mini-Map: Why Telemetry Matters

That’s where telemetry comes in—the hidden mini‑map you didn’t know you were missing. Business Central already emits the signals; you just need to surface them. With telemetry turned off, you aren’t choosing “less convenience.” You’re losing sight of how your environment actually behaves.

Helpdesk tickets alone? That’s reaction mode. Users only raise their hand when something hurts, and by then it’s already failed. Telemetry keeps the loop tight. It shows performance shifts and error patterns as they build, not just when the roof caves in.

Take deadlocks. By themselves, they’re quiet failures. Users rarely notice them until throughput explodes under load. In one real case, telemetry highlighted deadlocks tied directly to the Replication Counter update process. Enabling the “Skip Replication Counter Update” switch fixed it instantly. Without telemetry, you’d never connect those dots in time—you’d just watch payroll grind to a halt.

That’s the real power: turning invisible pressure into visible patterns. The dashboards let you spot the slope of trouble before it hits the cliff. It’s the difference between scheduling a fix on Tuesday afternoon and watching your weekend vanish into emergency calls.

And telemetry isn’t spying. It doesn’t capture who typed an invoice line or customer details. What it does capture are behavior signals—sessions starting and ending, login sources, SQL query durations, page views. Importantly, it covers both environment‑wide signals and per‑extension signals, so you aren’t locked into one dimension of visibility. It’s motion detection, not reading diaries.

Of course, all that data goes into Azure Application Insights. That means one requirement: you need an Application Insights resource in your Azure subscription, and you need the proper permissions to read from it. Otherwise, the reports will come up blank and you’ll spend time “fixing” something that isn’t broken—it’s just gated by access.

Compare that to raw error logs. They’re verbose, unreadable walls of text. Telemetry condenses that chaos onto dashboards where trends pop. Deadlocks line up on graphs. SQL lag shows up in comparison charts. Misbehaving extensions stand out. Instead of parsing twenty screens of stack traces, you just get a simple view of what’s wrong and when.

That clarity changes your posture as an admin. With only logs, you’re reacting to pain reports after they land. With telemetry dashboards, you’re watching the health of the system live. You can spot spikes before they take down payroll. You can measure “it’s slow” into actual metrics tied to contention, queries, or extensions. It arms both IT and dev teams with visibility users can’t articulate on their own.

And here’s the kicker: Microsoft already provides the feed. Business Central can emit telemetry into Application Insights straight out of the box. The dashboards in Power BI are what turn that feed into something usable. By default, you only see demo samples. But once you connect with the right credentials, the map fills in with your real environment.

That’s the unlock. It lets you stop working blind and start working ahead. Instead of asking, “why did it fail,” you start asking, “what trends do we need to solve before this becomes a failure.”

Now the next question is which tool to use to actually view this stream. Microsoft gives you two apps—both free, both sitting in Power BI’s AppSource store. They look identical, but they aren’t. Choosing the wrong one means you’ll never see the data you need. Think of it as two treasure chests waiting on the floor—you want to know exactly which one to open.

Picking Your Toolkit: The Two Power BI Apps

When it comes to actually viewing telemetry in Power BI, Microsoft gives you not one but two apps, and knowing the difference matters. These are the “Dynamics 365 Business Central Usage” app and the “Dynamics 365 Business Central App Usage” app. Both are free from AppSource, both open source, and both come with prebuilt dashboards. But they serve very different roles, and if you install the wrong one for the question you’re asking, you’ll be staring at charts that don’t line up with reality.

At first glance, they look nearly identical—same layout, same reports, same colors. That’s why so many admins spin them up, click around, and then wonder why they aren’t seeing the answers they expected. The split is simple once you know it. The “Usage” app is for environment telemetry. It covers cross-environment behaviors: logins, sessions, client types, performance across the whole system. Think of it like zooming out to see the whole town map in your game. The “App Usage” app, on the other hand, is tied to extension telemetry. It connects through app.json and focuses on one extension at a time—like checking a single character’s skill tree. Want to measure which custom app is throwing deadlocks or dragging queries? That’s what the “App Usage” app is for.

To make it easier, Microsoft even provides direct install links. For the environment telemetry app, use aka.ms/bctelemetryreport. For the extension telemetry app, use aka.ms/bctelemetry-isv-app. Both links take you directly to AppSource where you can install them into your Power BI workspace. After install, don’t be surprised when you first open the app and see sample data. That’s baked in on purpose. Until you connect them to your actual telemetry, they load with demo numbers so you can preview the layouts. They also automatically create a Power BI workspace under the same name as the app, so don’t panic if you suddenly see a fresh workspace appear in your list. That’s normal.

Now let’s talk capability, because both apps surface the same four report types—Usage, Errors, Performance, and Administration. Usage is your census ledger, capturing login counts, session timings, and client usage. Errors is the event list of failures, both user-triggered and system-level. Performance is where you spot long SQL durations or rising page load times before anyone raises a ticket. Administration logs environment events like extension installs, sandbox refreshes, and restarts—your system’s patch notes, all timestamped and organized.

All of those reports are available in both apps, but the scope changes. In the environment “Usage” app, the reports describe patterns across your entire Business Central setup. You’ll see whether certain clients are more heavily used, if session counts spike at end-of-month, or where contention is hitting the system as a whole. In the extension “App Usage” app, those same reports zero in on telemetry tied strictly to that extension. Instead of studying every player in town, you’re watching how your wizard class performs when they cast spells. That focus is what lets you isolate a misbehaving customization without drowning in global stats.

There is a cost gate here, though. While both apps are free to download, you can’t use them with live telemetry unless you have a Power BI Pro license. Without it, you’re limited to the static sample dashboards. With it, you get the real-time queries pulling from your Application Insights resource. That single license is the innkeeper’s fee—it’s what gets you from looking at mannequins to fighting your actual monsters. This is also why I flagged the subscription CTA earlier; if you’re planning to set this up, having Pro is not optional.

So, the practical workflow ends up being straightforward. Use the Dynamics 365 Business Central Usage app when you need system-wide telemetry, the big picture of how your environment behaves. Use the Dynamics 365 Business Central App Usage app when you want to isolate one extension and judge its reliability or performance. They aren’t competing apps—you’ll want both. One shows you patterns across the whole campaign, the other reveals weaknesses or strengths in a single party member.

With that toolkit installed, the next step is obvious. Right now the dashboards are running on sample skeletons. To bring them to life with your real environment, you need the key that unlocks Application Insights data. And that key comes in the form of a single code string—something buried in Azure that every admin has to hunt down before the charts mean anything at all.

The Azure Portal Puzzle: Finding the Application ID

The Azure portal is basically a maze. You expect neat hallways and labels, but what you get is blades, sections, and tabs that feel like they were designed to trip you up. Somewhere in that sprawl sits the one thing you need: the 36‑character Application ID inside Application Insights. Until you pull it out, Power BI won’t talk to your telemetry. Once you have it, the dashboards stop pretending and start reporting on your real system.

Here’s the first rule: you won’t find that Application ID in Business Central, and you won’t find it in Power BI. It lives only in Azure, inside the Application Insights resource that you connected to Business Central telemetry in the first place. Power BI treats it like a security pass. If the ID doesn’t match what Azure expects, you’re locked out. That’s where admins lose hours—copying the wrong thing, pasting it three more times, swearing it “should work,” but the portal just sits quiet.

The most common trap is the Instrumentation Key versus the Application ID. Azure shows you both, side‑by‑side, and they look technical enough to confuse even seasoned pros. The Instrumentation Key is legacy, used for writing telemetry into Insights. The Application ID is modern, used for reading telemetry out into tools like Power BI. Swap them by mistake, and Power BI won’t yell—it just refuses to return results. That silence is the worst kind of bug because it makes you think it’s a permissions glitch or a broken report.

To avoid that natural 1 roll, here’s the exact path. Sign into the Azure portal. Open the Application Insights resource you created for Business Central telemetry. On the left, look at the navigation blades. Scroll until you find “API Access.” That’s the door you want—not Overview, not Properties, not Keys. Click API Access and you’ll see the Application ID displayed right there. It looks like a GUID: thirty‑six characters with hyphens splitting the sections. Highlight it carefully. Copy it to your clipboard. That string is what you’ll paste into Power BI when setting up the app.

It sounds obvious, but precision matters here. One missing character or an extra space, and the connection fails. The Application ID is a lock pick cut for a single tumbler; close enough is still wrong. If you’ve ever watched someone insist the app is broken only to realize they pasted the Instrumentation Key instead, you already know most of the headaches are self‑inflicted.

There’s one extra safeguard to mention. When you connect Power BI to Application Insights, leave the authentication method set to OAuth2. That’s the supported handshake. If you see an error along the lines of “OAuth authentication method isn’t supported for this data source,” don’t waste half a day chasing ghosts. Nine times out of ten, you just pasted the wrong ID. Swap in the proper Application ID, and the error vanishes.

Permissions can trip you here too. Even with the perfect ID, you won’t get data unless your account has read access to the Application Insights resource. And because everything lives under Microsoft Entra tenants, you need to be in the same tenant as the Insights instance. If you’re crossing tenants, you’ll need an API key alternative. So before you rage at the dashboards, sanity check: Am I in the right tenant? Do I have read access? Solve those two, and most connection failures disappear.

One more point of confusion I’ve seen: mixing up the Lookback setting in Power BI with the Application ID. They’re completely different. The Application ID says “which telemetry vault are you connecting to.” The Lookback decides “how many days of past data do you want to pull in.” Set the wrong Lookback and you only pull a slice of your history. Set the wrong Application ID and you get nothing at all. Keep that mental split and you won’t waste cycles troubleshooting the wrong thing.

The moment you copy the correct Application ID, the puzzle is over. Now instead of guessing at random doors, you’re holding the key that actually fits the lock. Once you bring that into Power BI, the placeholders give way to real telemetry—errors, usage, admin actions—all tied to your own environment.

And that takes you straight into the next step: wiring this ID into your Power BI app so the dashboards stop running on samples and start running on the live feed that matters.

Wiring the Connection: From Sample Data to Live Dashboards

Nothing kills the mood faster than opening the telemetry app in Power BI and realizing the “data” is just a demo show—fake users, fake sessions, fake quests. It looks alive but it’s not your world. To make the dashboards yours, you only need two required parameters: the Application Insights Application ID and the Lookback period. Those two fields are what shift the app from mannequins to live signals.

The Application ID you already pulled from Azure’s API Access menu is the key. Drop that 36‑character code into the Power BI setup screen, confirm OAuth2 is selected, and you’ve unlocked the connection. Right below it sits the other lever: Lookback. That setting tells Power BI how many days it should rewind and fetch telemetry. Three days is handy for quick triage if you want to chase down a fresh ticket. Thirty days gives you a better view of adoption and repeated slowdowns. Be careful with extremes. A massive time window drags refreshes into the mud. A window too short leaves you blind to long-term patterns.

Beyond those two, the app gives you a few optional tweaks worth your attention. If you’re juggling multiple domains, map your Microsoft Entra tenant so the dashboards label data correctly across environments. Adjust the timezone, because Business Central feeds all telemetry in UTC. Until you set it, your “midnight spike” may just be 5 p.m. local wrapped in UTC disguise. Then set a refresh schedule that fits your needs. By default, the app refreshes sample data nightly. Once you’ve connected to live telemetry, you decide how often the dataset updates in Power BI service. Every few hours if you need near real-time chatter, once a day if you’d rather conserve resources.

Treat one point as gospel: once you wire the app to an Application Insights resource, sample mode is gone. There’s no toggle to flip back—if you want the demo again, you reinstall a fresh copy. That trips up testers who expect to play with both environments in one app. Another wrinkle? If you disable scheduled refresh, some configurations can forget the Application ID. That means you’ll be forced to paste it back in before the app works again. Neither quirk is obvious, so keep both in the back of your mind.

Now the gotchas. If the dashboards stay empty, run down a quick four‑part checklist before blaming Azure. One: check you used the Application ID, not the Instrumentation Key. Two: confirm you selected OAuth2 as the authentication method. Three: make sure your account has read access to the Application Insights resource, and that you’re in the right Entra tenant—or you’ve set up an API key if you’re crossing tenants. Four: trigger a dataset refresh after changing settings. Most “broken” connections are one of those four.

Do that, and the switch flips instantly. Mannequins vanish. Real errors, session spikes, and admin actions appear over charts that now breathe with your environment’s rhythm. Refresh discipline completes the picture. Without it, yesterday’s fights keep looping in the book while today’s burns go undocumented. With it, every session leaves a footprint you can track, and every deadlock becomes a pattern to solve instead of a ghost story.

With the connection stable, the stage is finally set. The placeholders are gone, the data stream lives, and you’re staring at dashboards waiting for interpretation. The next step isn’t wiring anymore—it’s about knowing what each page actually shows, and which questions each answer can solve.

Unlocking the Four Reports: Usage, Errors, Performance, Administration

Once the wiring is done, the real insight comes from the four reports Power BI delivers: Usage, Errors, Performance, and Administration. Each has a specific role, and the fastest way to use them is to map problems directly to the right page. Need to check adoption? That’s Usage. Hunting a recurring failure? That’s Errors. Tracking slowdowns and bottlenecks? That’s Performance. Figuring out what changed before stuff broke? That’s Administration. Simple rules, no wasted clicks.

Start with Usage. This is your census ledger, but also your proof-of-life report. You’ll see who’s logging in, from where, and what devices they’re using. More importantly, the Page Views and Feature Usage subpages tell you if a new rollout is actually getting touched, or if UAT (user acceptance testing) is just sitting in the queue. If your job is to validate adoption, manage licenses, or double-check that a training group really used a new module, this is where you confirm it.

Flip to Errors when the helpdesk tickets pile up. The Errors report collects system-level failures and user missteps, but it organizes them in ways raw logs can’t. Start triage by checking concrete pages: Login Errors if people are struggling to sign in, Error Dialogs if Business Central is visibly throwing screens, Permission Errors if security roles block essential navigation, and Database Deadlocks if you think contention is killing throughput. Stack up enough of the same failure and the pattern jumps out. That’s what saves you from treating fifty support tickets like fifty separate mysteries.

Performance is where most admins earn their keep. Instead of vague user complaints—“it’s slow today”—here you can see actual work failing the speed test. Long-running SQL queries show up plainly; anything that consistently runs past 750 milliseconds is a red flag inside the app. You’ll also see OnCompanyOpen timings, so if a session groans every time someone opens the tenant, you’ll know. Database lock timeouts greater than 15 seconds surface immediately, showing where contention is stalling. And you even get visibility into long-running AL methods that take more than 10,000 milliseconds. Each metric is a measuring stick that turns “gut feeling” into proof. If a report is crawling, you’ll see exactly why, and whether it’s a one-time spike or a growing pattern.

Administration is quiet but crucial. This page is your ledger of everything structural: state changes, extension installs, sandbox refreshes, restarts, and patches. For quick analysis, the All Changes page is often the best starting point. If payroll lagged Friday after running fine Thursday, check the log of extensions installed or patches applied. Being able to line up “this changed here, performance fell afterward” cuts through the blame loop between IT, developers, and business units. Instead of finger pointing, you have a timestamped map of cause-and-effect.

Using these reports together paints a complete picture. Usage shows whether adoption is climbing or slipping. Errors points you to functions users don’t understand or to code paths that keep failing silently. Performance highlights where the engine stalls. Administration ties outcomes back to specific changes. None of these alone solves production pain, but combined they give admins, developers, and project leads the visibility needed to move from reactive firefighting to proactive maintenance.

Research-backed cases prove the value. Deadlocks tied to the Replication Counter process weren’t obvious in user reports. Telemetry revealed the problem with stark clarity, and enabling Skip Replication Counter Update fixed it without guesswork. Problems like this don’t wait until projects are convenient—they hit under load. With the Performance and Errors reports pulled together, the outline of the trouble was visible and actionable long before it blew up payroll.

If you’re advanced and want even finer-grained control, remember you can export KQL directly from Azure Logs to Power BI. From the Logs screen in Azure, any custom KQL query you build can be exported as an M query and reused inside Power BI. That option lets you go beyond Microsoft’s four pre-cooked reports and tailor dashboards to unique questions your environment raises. It’s optional, but the door is open if you want to push deeper later.

Treat these reports like a toolkit, not a monolith. Each one answers a different category of question, and knowing which lever to pull saves you both time and stress. Once you work this way, the anxiety of hidden issues fades. Problems stop being invisible booby traps and start becoming patterns you can manage.

And that realization sets the stage for the final truth: running without telemetry isn’t just inefficient—it’s gambling. No vision, no plan, just dice rolls. With dashboards up and live, you’re finally out of the dark.

Conclusion

Telemetry changes your role from putting out fires to working with clear, measurable signals. It moves you from reacting after tickets explode to steering production with data you can trust.

Here’s your quick next step list: create an Application Insights resource in Azure if you haven’t already, install the right telemetry app from Power BI AppSource, copy the Application ID from API Access into the app, and then set your Lookback window and a refresh schedule that makes sense for your load.

If this walkthrough saved you time, hit subscribe and drop a comment with the one trick that’s bailed you out of a production jam—or tell me if you want a deeper dive into KQL or alerting tricks.

That’s it. No magic, no dice—just data and deadlines.

This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit m365.show/subscribe