Learn › Power Apps & Platform › 4 · ALM & operations

Monitoring and analytics

You cannot govern what you cannot see. The Power Platform's monitoring surface spans Purview activity logs, admin-center analytics and the environment/DLP inventory — the raw material for a change-intelligence loop that catches drift.

The monitoring surfaces

There are three layers worth wiring together:

Surface What it gives
Purview audit (activity) log Power Apps and Power Automate activity events — app launched, flow created/edited, DLP changed, sharing changed
Admin-center analytics Usage, performance and (in Managed Environments) weekly digests of active/inactive assets
Inventory / config state Environments, apps, flows, connectors, DLP policies — the current shape, from the admin cmdlets/APIs

Activity logging for Power Platform must be enabled (Power Apps and Power Automate activity events flow into the unified audit log in Microsoft Purview); without it you have config state but no history of who changed what.

The change-intelligence loop

Config state answers 'what is true now'; the audit log answers 'what changed and who did it'. Governance value comes from the loop between them: snapshot the environment/DLP/inventory surface on a schedule, diff it against the last snapshot, and correlate deltas with audit events. A DLP policy loosening, a new environment, a connector moving to the business group, an app newly shared to 'everyone' — each is a dated, attributable drift signal. serv365 runs exactly this nightly-scan-plus-diff loop so a governance regression surfaces as an alert rather than a post-incident discovery.

Failure modes

  • Auditing never turned on. No Power Platform activity in Purview means no forensic trail — the most common gap.
  • Retention too short. Audit retention defaults vary by licensing; a 90-day window loses the slow-drift story.
  • Config-only monitoring. Watching current state without diffing history misses who changed a policy and when — you see the hole, not the cause.
  • Alert fatigue / no baseline. Without a known-good baseline, every maker action looks like noise; drift detection needs a reference to diff against.

What to watch (proofs)

  • Audit is enabled and flowing: Search-UnifiedAuditLog for Power Apps / Power Automate record types returns events — the presence of results is the proof logging works.
  • Config snapshots to diff: Get-AdminPowerAppEnvironment, Get-AdminPowerApp, Get-AdminFlow, Get-DlpPolicy captured on a schedule — the baseline for drift detection.
  • Key drift events: DLP policy changed, environment created, app/flow sharing changed — correlate the config delta with the Search-UnifiedAuditLog actor.
  • Retention setting vs the drift window you need — a short window is the blind spot.

PowerShell for this concept

  • Search-UnifiedAuditLog Search the unified audit log. This log contains events from Exchange Online,...
  • Get-AdminPowerAppEnvironment
  • Get-AdminFlow
  • Get-DlpPolicy **Note**: This cmdlet is retired from the cloud-based service. For more information,...

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.