Power Platform Security Week Day 7: Activity Logs & API Insights: What They Reveal (and Hide)

Power Platform Security Week Day 7: Activity Logs & API Insights: What They Reveal (and Hide)

In the world of the Microsoft Power Platform, where low-code apps, flows and automations drive business value at speed, security and governance must keep pace. On Day 7 of our Security Week series, we’re focusing on that often-under-appreciated corner: activity logs and API insights. These silent record-keepers hold rich clues about what’s happening in your environments — and equally important, what they don’t capture. Understanding both sides helps you build stronger oversight, faster incident response and more robust audit readiness.

What the Logs Give You

Activity logs in the Power Platform context capture user and system actions: environment creations, settings changes, app launches, flows executed, connector calls, and so on. Thanks to built-in logging in environments via the unified audit stream, via Microsoft Purview auditing, and via integrations like Azure Application Insights, you can access a rich telemetry set.

For example:

• The admin-activity logs for Power Platform environments (via Purview) list operations such as environment creation, deletion, property changes, environment group manipulations, licensing or billing policy updates.
• The CoE Starter Kit documentation shows how the audit logs from Office 365 Management API or Graph API can feed into usage dashboards for app launches, unique users and other telemetry.
• From a developer angle, if you connect your canvas app to Application Insights, you can capture usage events (screens visited, device types, browser versions) and even custom traces.

Because of this, logs provide several key benefits:

• Visibility: You can see who did what, when, and in what environment. For example, if someone added a guest user to an environment or changed sharing permissions, that shows up.
• Forensics: If something goes wrong (a flow unexpectedly fails, an environment gets rolled back, or apps propagate an unwanted change), logs provide the breadcrumbs.
• Governance/Compliance: Many regulatory frameworks require audit-trail capabilities — logs fulfill part of that need. For example, an organisation’s blueprint emphasises that Power Platform activities should be logged and retained.
• Behavioural Insight: Beyond security, you can leverage logs to understand usage patterns: which apps users engage with, what devices they use, how flows are triggered. That insight helps you optimise usage and reduce risk (e.g., isolating seldom-used apps or auditing high-risk ones).

In short: logs are powerful. They give you the what, when, who, where of actions in your Power Platform tenant.

What the Logs Don’t Always Show

But—and this is a critical “but”—activity logs and API insights come with limitations. Ignoring those gaps can lead you into a false sense of security. Let’s explore some of the key blind spots.

Context & Intent

Even when a log entry shows “User X changed App Y’s permissions”, the log may not reveal why the change was made or whether it was authorised. Logs tend to capture metadata — operation name, timestamp, affected object — but frequently lack narrative context: was this a deliberate cleanup, or part of a malicious lateral move? Without deeper context (e.g., discussion threads, ticket records) you’re making interpretation. Logs reveal actions, not always motives.

Coverage Gaps

• Some connectors, flows or custom APIs may not have full telemetry in the unified logging stream. For example, application-side telemetry in a canvas app might rely on custom Trace functions (in Application Insights) and unless that is configured, you may miss those events.
• Logs may exist in various stores (Dataverse audit tables, unified audit logs, Application Insights) and unless you centralise them, you may miss cross-environment correlations.
• Retention and archive policies may limit what historical data you can access. If old logs are purged, your retrospective investigations shrink. For example, one modern blog notes audit data being offloaded to Azure Synapse for long-term retention because Dataverse storage and retention may become costly.

Latency & Real-Time Constraints

Many audit flows run on schedules (hourly, daily) not real-time streaming. If a malicious actor acts quickly and then deletes or hides traces, there may be a window where damage is done before logs surface. Also logs often reflect “event happened” not “event is happening”, so you may lack real-time alerts unless you build them.

Depth of Detail

While the schema for logs is well-defined (especially in Purview) — e.g., event types like NewEnvironmentGroup, CreateRuleSetOperation, ChangePropertyOnEnvironment etc. — the granular detail may not always be at the level you need. For example, a “Changed property on environment” event might capture the display name change, but not show the previous value, who requested it or whether it was reviewed. Similarly, for canvas apps with Application Insights enabled, correlation tracing depends on the connector being also instrumented. If a custom connector or third-party service isn’t wired in, you lose visibility.

Hidden Dependencies & Shadow Usage

Logs may capture the action but not always the downstream consequence. For example: a user grants “Editor” access to a canvas app. The log shows the grant. But whether that Editor account then created malicious data extraction or copied sensitive data might not be visible unless you also log data-access events or monitor unusual data flows. In other words: just because the permission was granted doesn’t mean you tracked its misuse.

Maximising the Value of Logs & APIs

Given the strengths and limitations, how can you make your activity logs and API insights work better for your security posture?

Centralise and Normalise Logging

Ensure that you’re ingesting audit logs from all relevant sources: the Power Platform admin activity logs via Purview, unified audit logs for Power Apps/Power Automate usage, Application Insights telemetry for canvas and model-driven apps, and any relevant API logs (such as the Activities API in cloud apps). For instance the Microsoft Defender for Cloud Apps Activities API allows listing of user actions across cloud apps and filtering by action types.

By consolidating logs into a central SIEM or log analytics workspace you gain cross-environment visibility and can correlate events (e.g., a flow triggered in one environment followed by unexpected data access in another).

Enrich Logs with Context

Add custom telemetry where possible. For example, with canvas apps using Application Insights, capture custom trace events for key user actions (log-in, form submission, data export) and include fields like user role, session ID, and app version. The community article shows how using a “SessionRef” custom field helps filter logs per user session. Also map logs back to your change-management records, ticketing system, or governance board. If a permission change event happens, ensure there’s a contextual ticket ID in the metadata to link back to business approval.

Use APIs for Automation and Alerting

Leverage the APIs to automate ingestion, build dashboards and trigger alerts. For example, the Setup of the audit-log flows using the Office 365 Management API or Graph API (as shown in documentation) ensures automated collection rather than ad-hoc manual export.

Set alert rules for high-risk events like: environment deletion, hard-delete, role change for system administrator, or unusual spikes in app launches or API calls. Use query languages in Application Insights or log analytics to monitor for threshold breaches (e.g., many failed API calls in short time).

Archive, Retain and Affirm Recovery

Logs are only as useful as your ability to query them after the fact. Ensure you have a clear retention policy. For large-scale environments, exporting audit tables to a data lake via tools like Azure Synapse Link may help manage cost and scale. Establish procedures for long-term storage (3-7 years) and for data recovery (if logs are corrupted or deleted). The security blueprint highlights the need to retain logs in line with organisational evidence retention policy.

Recognise and Compensate for Blind Spots

Because no logging mechanism is perfect, identify where your visibility is weak and compensate accordingly. For instance: if you have connectors that are not instrumented, consider placing additional monitoring or data leak prevention (DLP) controls there. If you have applications developed outside the standard telemetry architecture, build periodic manual reviews or snapshots. Use log-analytics queries that look for anomalies rather than just known patterns.

Final Thoughts

On Day 7 of our Security Week journey, hopefully the picture is clear: the activity logs and API insights in Power Platform aren’t just optional—they’re foundational for security, audit, governance and operational oversight. They empower you to answer the core security questions: What happened? Who did it? When and where did it occur? Yet they also require deliberate thinking to ensure you’re not blindsided by what they don’t show.

By centralising, enriching, automating and preparing for gaps, you turn logs from passive records into active defenders. And by building awareness of blind spots — coverage gaps, latency, depth limitations, hidden downstream consequences — you avoid over-reliance. The takeaway: logs are a vital tool, but they are not the whole tool. Use them wisely, complement them appropriately, and ensure they evolve with your environment.

Source: Power Platform Security Week Day 7: Activity Logs & API Insights: What They Reveal (and Hide)