How the portal works

Almost every monitoring tool asks for credentials to your system and reaches in to fetch data. This portal does not. The flow runs the other way, and that changes several things for the better.

The problem

Handing a third party credentials to your Finance and Operations environment is a risk that is hard to justify to security, and building your own Application Insights setup means provisioning Azure resources, writing KQL queries and maintaining them when Microsoft changes the schema. The first option is uncomfortable; the second is a project.

The approach

The portal provisions the telemetry infrastructure for you and gives you back a connection string. You paste it into a screen D365 already ships, «Monitoring and Telemetry parameters», and from then on it is your environment that sends data. The portal never reaches into your system.

• Your D365 environment emits telemetry toward your organization's destination.
• The destination stores it for your plan's retention window.
• The portal queries it when you open each screen and turns it into charts and tables.

Per-organization isolation

Each organization gets its own dedicated infrastructure, not a shared store with per-customer filters. The practical consequence is that the ingestion cap and retention are enforced by the platform, not by an interface check somebody could bypass.

Inside the portal, data access is always resolved from the user's membership in the organization, never from a request parameter. An organization identifier in a URL grants nothing.

What you give up

• The Azure region is chosen once and never changed: the resources exist and moving them would cost the ingested data.
• There is a delay of minutes between something happening in D365 and it showing up in the portal. This is not a real-time monitor.
• If somebody pastes the string into the wrong environment, that telemetry arrives anyway. That is why environments are registered with their identifier: it is what lets you separate it afterwards.