What it does

An environment-level data export that pushes Power Automate telemetry into your own Application Insights resource, where you can query it with KQL, build dashboards and raise Azure Monitor alerts on flow failures.

Key facts

• Turned on and supported for Managed Environments only.
• Configured in the admin centre under Manage > Data export > App Insights tab > New data export. You pick the Application Insights instance, choose Power Automate as the data type, and select whether to export cloud flow runs, triggers, actions, or a combination.
• Telemetry lands in two tables. Requests holds cloud flow runs. Dependencies holds cloud flow triggers and actions.
• Data starts flowing within 24 hours of setup, and the stated SLA for delivery of telemetry to Application Insights is 24 hours.
• Filtering is done on custom dimensions: environmentId for environment, resourceId for the flow ID, signalCategory to separate runs from triggers from actions. Operation name maps to the flow ID for runs and to the trigger or action display name for dependencies.
• For alerting, cloud flow runs map to the Server Requests signal (so Failed requests = flow run failures) and triggers/actions map to Dependency calls (so Dependency call failures = action or trigger failures).
• Custom log search lets you write a KQL condition for a specific environment, flow or action rather than alerting at instance level.
• Multiple environments can log into the same Application Insights resource.
• Not available in sovereign clouds — GCC, GCC High and DoD are excluded.
• The telemetry stream isn't transactional and isn't 100% lossless. Small gaps can occur from transient service issues. The portal run history remains the authoritative record.

When to use / skip

This is the right answer whenever the client has an existing Azure Monitor practice and treats flows as production systems. You get retention on your terms, cross-correlation with Power Apps and Dataverse telemetry through correlation IDs, real alerting, and query access to trigger and action-level detail that the portal won't give you at scale. Skip it if the estate is a dozen flows and nobody owns an Azure subscription — a failure-notification flow will cover it for a fraction of the effort. The Managed Environments requirement makes the decision for you in a lot of tenants.

Configuration decisions

• Which environments export, and whether they share one Application Insights resource or get their own.
• Whether you export runs only, or runs plus triggers plus actions. Actions are where the diagnostic value is and where the ingestion volume is.
• Who owns the Application Insights resource, its retention setting and its ingestion cost — this is an Azure bill, not a Power Platform one.
• Whether alerts are instance-wide out-of-the-box rules, or custom log search scoped to specific flows.
• What the action group does when an alert fires — email, Teams via webhook into a flow, or an incident in the client's ITSM tool.

Gotchas

• Managed Environments is a hard prerequisite. Clients often discover this after they've designed a monitoring approach around it.
• The 24-hour SLA is for delivery, not a promise of immediacy in practice. Don't build a five-minute incident response expectation on it without testing.
• Ingestion cost is real and grows with action-level export on a busy environment. Turn on action telemetry deliberately, not by default, and watch the first month's bill.
• The lossy-stream caveat matters if anyone plans to use this as an audit record. It's a monitoring feed. Reconcile against portal run history when the answer has to be exact.
• Operation name for runs is a GUID, not a friendly flow name. Your dashboards need a lookup or nobody will read them.
• Sovereign cloud exclusion rules this out entirely for a meaningful set of public sector clients.

Consultant notes

• Get the Azure side sorted early. Creating the Application Insights resource, agreeing retention and getting cost approval typically involves a different team and a different budget from the Power Platform work.
• Sell it as making flows visible to the existing monitoring practice rather than as a new tool. Clients with an Azure Monitor capability already know what to do with the data.
• Build the flow ID to flow name mapping once and reuse it. Every client who skips this ends up with dashboards full of GUIDs that get ignored.
• Pair it with a failure-notification flow rather than replacing one. The alerting is better, but the flow-based version keeps working when the Azure side is misconfigured, which it will be for the first fortnight.

---

Check whether sovereign cloud support has arrived before proposing this to a public sector client.