AI agents are beginning to play a larger role in everyday business processes—from researching prospects and updating records to supporting outreach and follow-up. As organizations explore these possibilities, it is helpful to have a clear and manageable way to understand which agent is taking action and what it is permitted to do. 

Microsoft Entra Agent ID and Dataverse agent users offer a new identity foundation for these scenarios. Together, they help organizations give each agent a dedicated identity for accessing Dataverse, assign appropriate security roles, and maintain visibility into the agent’s activity. 

This approach can help teams introduce agent-based experiences thoughtfully, with clearer separation between people, applications, and autonomous agents.

What is Microsoft Entra Agent ID? 

Microsoft Entra Agent ID extends Microsoft Entra with identity constructs designed for AI agents. Instead of treating an agent as an anonymous automation or sharing a generic application identity, an organization can give the agent an individually identifiable, policy-controlled identity with its own permissions and audit trail. 

How Dataverse agent users complete the model 

When an agent needs to work with business data in a Dataverse environment, an administrator creates a Dataverse agent user associated with the agent’s Entra identity. The agent user becomes the security principal inside that environment, where it can be assigned dedicated, least-privileged Dataverse security roles. 

• Authenticate the agent: Establish a distinct enterprise identity for the agent. 

• Authorize only what it needs: Assign Dataverse security roles aligned to the agent’s intended tasks. 

• Separate duties: Distinguish agent activity from human users and conventional application integrations. 

• Audit agent actions: Attribute data access and changes to the agent identity. 

• Manage the lifecycle: Apply administrative ownership and governance as the agent is created, updated, or retired. 

Why this matters 

Agent identity turns governance into an architectural capability rather than an afterthought. Security teams gain clearer accountability, administrators can enforce least privilege, and makers can build agentic experiences on a foundation designed for enterprise access and compliance. 

Example: Sales Development Agent 

Consider a Sales Development Agent that helps a sales organization keep up with a large volume of prospects. The agent can continuously research leads, prepare personalized outreach, follow up, and hand promising leads to sellers. To do that responsibly, it needs access to CRM data—but it should not inherit broad permissions or operate under a shared identity. 

How the identity-enabled flow works 

1. The agent receives an Entra agent identity. The identity establishes the agent as a distinct nonhuman actor that the organization can manage and govern. 

2. The Power Platform administrator adds the agent to Dataverse. A Dataverse agent user is created and associated with the Entra agent identity. 

3. The Power Platform administrator assigns a purpose-built security role. For example, the role can permit the agent to read and update eligible leads, create activities, and record outreach outcomes—without granting access to unrelated tables or sensitive fields. 

4. The agent works within those permissions. It researches assigned leads, evaluates fit, generates or sends approved outreach, follows up, and updates lead status according to the configured sales process. 

5. Actions remain attributable. Administrators can distinguish changes made by the agent from those made by a seller or a conventional application user. 

Get started with the public preview 

Start in a non-production environment and identify one well-bounded agent scenario. Define the data and operations the agent needs before assigning permissions. 

1. Create or enable the agent identity through a supported Microsoft agent creation experience. 

2. In the Power Platform admin experience, add the Entra agent identity to the target Dataverse environment as an agent user. 

3. Assign a dedicated Dataverse security role that follows least-privilege principles. 

4. Test expected and denied operations, and verify that the agent’s actions are visible in your audit and monitoring processes. 

5. Document the business owner, security owner, intended purpose, and retirement process for the agent. 

Preview reminder: Preview capabilities are intended for evaluation and may have restricted functionality. Validate availability, licensing, regional support, and current documentation before adopting the capability for production workloads. 

Build agents the enterprise can trust 

The next generation of business applications will include people and agents working side by side. Microsoft Entra Agent ID and Dataverse agent users help make that collaboration secure by design: every agent can have a recognizable identity, only the access its role requires, and an auditable record of its work. 

Explore the public preview, test a scoped scenario such as sales development, and share your feedback with the Power Platform community. What business process would you entrust to an agent with its own governed identity? To Learn more: 

• Microsoft Entra Agent ID documentation | Microsoft Learn 
• Dataverse Agent User: Create Entra agent users (preview) – Power Platform | Microsoft Learn 

The post Secured and Governed your AI Agents: Microsoft Entra Agent ID for Dataverse  appeared first on Microsoft Power Platform Blog.

What is changing and why we are making this change?

Three things drove this refresh, all rooted in customer feedback and where the product is going.

1. The name no longer matched the product.

“Azure Synapse Link for Dataverse” was created when Azure Synapse Analytics was the only destination. Today, most new links go to Microsoft Fabric, and we ship updates to Fabric link on a far faster cadence than any other path. Keeping “Synapse” in the name was sending the wrong signal to customers evaluating their data architecture and was creating confusion in support tickets, partner conversations, and search results.

2. Fabric link creation was hidden in the wrong place.

In the old experience, the Azure Synapse Link page was where you went to see and manage your links, but its + New link button only created a Synapse link with your own storage. To create a Fabric link, you had to leave that page entirely, go to the Tables area, and choose Analyze > Link to Microsoft Fabric. Two surfaces, two mental models, and no clear signal that Fabric link was the recommended path. The new Link data page consolidates link management and link creation into one place, with Fabric link as the headline tile. The Tables > Analyze > Analyze in Fabric entry point still exists for in-context Fabric link creation, but Synapse link creation has been removed from the Tables page (Synapse links are now created only from the Link data page, under Other Links).

3. Authentication needs to get simpler and safer.

Workspace identity removes the most common Fabric link setup failure mode: misconfigured service principal permissions. It is also the path our security and platform teams recommend. Until now, it was an option you had to know to look for. The new wizard calls it out as the recommended choice and links straight to the Fabric docs for enabling it on your workspace. Workspace identity is configured on the Fabric workspace itself (outside Dataverse), so this is a one-time setup your Fabric admin does once per workspace, and every Dataverse link to that workspace benefits.

See the below video to see how you can setup Fabric Link using a refreshed user experience.

From “Azure Synapse Link” to “Link data”

The left navigation entry in the Power Apps maker portal is now Link data. The landing page groups your links under two clear sections:

• Fabric Links: the recommended path for new analytics workloads. See Configure your environment and link to Microsoft Fabric.
• Other Links: Azure Synapse Link with your own Synapse workspace and Azure Synapse Link with Azure Data Lake continue to work here without any change.

Existing links keep running. There is no migration step. Any Azure Synapse Link you already have will automatically show up under the Other Links section on the new Link data page; you do not need to do anything to move it. If your runbooks or internal documentation reference “Azure Synapse Link for Dataverse”, update them to point at Link data.

We are also consolidating where links get created. The New link entry point for Azure Synapse Link with Azure Data Lake on the Dataflows page now redirects to the Link data page. Wherever you start, link creation now lands in the same place.

The new Link data page in the left navigation of the Power Apps maker portal, with Fabric Links as the headline section and Other Links below.

A redesigned Fabric link wizard

Creating a Fabric link now starts from the Link data page itself (no more hopping over to the Tables area) and walks you through three steps:

1. Setup Configuration. Pick the Fabric workspace you want to link to and choose how to authenticate. Workspace identity is called out as the recommended option, with organizational account and service principal still available.
2. Select Tables. Pick the Dataverse tables to sync,
3. Review & Create Review your workspace, authentication, and table selections, then create the link.

The Setup Configuration step: pick your Fabric workspace and connect, with workspace identity called out as the recommended authentication.

The post-create experience drops you directly into a standalone Manage tables experience, reachable any time from the top command bar. You no longer have to click on the link to add or remove tables.

The standalone Manage tables option, reachable from the top command bar at any time.

Workspace identity is the recommended authentication

The Setup Configuration step calls out workspace identity as the recommended option and points you at the docs for enabling it. Service principal and organizational account continue to work and remain selectable from the same step. The trust model is documented in Authenticate with workspace identity.

One thing to know up front: workspace identity is a property of the Fabric workspace, not of the Dataverse link. You enable it once on the Fabric side, outside of Dataverse, via the Fabric workspace identity docs. Once it exists on the workspace, the Fabric link wizard can use it, and the Configure Fabric link to use workspace identity section shows how to wire it into an existing link.

What this means for your team

Fabric link is the strategic path. Link data puts Fabric link front and center in the UI and in our roadmap. If you are deciding where to invest for new analytics workloads, this is the option we are building on.

One consistent UX for every link. Whether you are creating a new Fabric link, managing an existing one, or maintaining a Synapse link, you start and end on the same Link data page with the same look, the same controls, and the same docs. Learn more: For the updated end-to-end setup walkthrough, see Link your Dataverse environment to Microsoft Fabric.

What is not changing

• Existing links keep working. No migration, no relink required.
• Azure Synapse Link, Azure Data Lake, and other targets are still fully supported under Other Links.
• APIs and admin automation for existing flows are unchanged. The rename is a UX and Information Architecture change, not a contract change.
• Pricing and metering are unchanged.

Looking ahead

Link data is the umbrella we will keep building under. Two improvements we are actively working on:

• Easier table selection. Picking tables one at a time is cumbersome for large environments. We are working on a faster, more flexible selection experience so you can get to the set you need with far fewer clicks.
• Multiple Fabric links to different workspaces. Today an environment links to a single Fabric workspace. We are adding support for creating multiple Fabric links from the same Dataverse environment to different Fabric workspaces, so different teams and workloads can each have their own target.

Beyond those, expect continued investment in Fabric link as the primary sync path (including the low-latency sync engine that is rolling out now) and more guided setup so customers always know which path to invest in.

We want your feedback

If you set up a new Fabric link in the next few weeks, we want to hear what worked and what did not in the new wizard, especially around workspace identity.

• Share feedback: post on the discussion in our Viva Engage community. Not a member yet? Sign up here.
• Try it now: create a new Fabric link from the Link data page in the Power Apps maker portal.

The post Announcing Link to Fabric UX refresh appeared first on Microsoft Power Platform Blog.

Bulk Deletion is the native Dataverse capability built to prevent exactly that. In this post, we’ll cover what Bulk Deletion is, how to use it as part of a data lifecycle management, and the improvements that are now general available beginning June 2026. 

What is Bulk Deletion? 

Bulk Deletion is a native Dataverse capability that lets administrators define and run jobs to remove large volumes of records based on a query. Instead of writing custom scripts or one-off automations, admins configure a query, for example, “all completed system jobs older than 90 days” and let the platform execute the deletion in the background. 

A bulk deletion job can be: 

• Run once on demand for ad-hoc cleanup. 

• Scheduled to recur on a daily, weekly, monthly, half-yearly, or yearly cadence. 

• Configured with notifications so administrators get email alerts when a job completes. 

• Targeted at any table including system tables and custom tables. 

Under the hood, Bulk Deletion respects security, cascading rules, plug-ins, and workflows. It behaves like a regular delete, just at scale and on a schedule. 

When should Bulk Deletion be used? 

Use Bulk Deletion any time you need to remove a meaningful volume of records based on a repeatable, query-based rule. Common scenarios: 

• Staying storage compliant. Keep your environment within Dataverse storage entitlements by routinely removing data that no longer needs to be retained, before it pushes you into overage. 

• Routine system hygiene. Purge data from system tables, completed system jobs, workflow logs, plug-in traces, audit records, once they pass their retention window. 

• Post-migration cleanup. Remove staging records, or test data after a migration has been validated. 

• Sandbox refresh follow-up. After copying production into a sandbox, remove PII, large transactional tables, or data not relevant to dev/test. 

• End-of-lifecycle data. Clear out closed cases, expired leads, or transactional records past their business retention period. 

• Enforcing custom rules. Implement organization-specific rules like “delete all inactive accounts older than 60 days.” 

If the rule for what to delete can be expressed as a query, Bulk Deletion is almost always the right answer. 

How Bulk Deletion should be used — setup deletion jobs on day one 

The single most important guideline: define data deletion jobs the day an environment is provisioned for any table likely to accumulate data that will eventually no longer be needed. 

A data deletion job is a documented rule, per table, for what to delete, when to delete it, and how often the rule runs. It is also called a bulk delete job. Without one, environments tend to follow a predictable pattern: 

• Transactional and log tables grow unchecked. 

• Audit and workflow data is never purged. 

• Custom tables built for transient processing become permanent stores. 

• Storage usage climbs. 

• Cleanup eventually stops being routine and becomes a project. 

Treat data deletion as a Day-1 design decision, alongside security roles, solution architecture, and integration design. 

Setting a data deletion job 

For every table, system or custom, one should answer these three questions: 

1. Does this table accumulate transactional or log data? 

2. How long does the business need to retain this data? 

3. Is there a recurring bulk deletion job in place to enforce that? 

If the answer to (3) is “no” for any table that grows, you are accumulating storage and operational debt. Schedule a recurring bulk deletion job up front. Even a simple weekly job that removes records older than your retention window will hold the table at a steady state. 

Think of a data deletion job the way you’d think of garbage collection in a running application, a routine, automated process that keeps the system healthy, not an afterthought once memory runs out.

What administrators have been telling us 

As Dataverse adoption has scaled, three themes have come up consistently: 

• “My job stopped, and it wasn’t clear why.” Jobs could stop or hit issues mid-run, but the reason wasn’t always visible. Admins often re-ran jobs to move forward, which added guesswork. 
• “I had to recreate the same job in every environment.” As solutions moved from dev to test to production, bulk deletion configurations had to be set up manually in each environment. Small differences, a filter, a schedule, required careful revalidation. 
• “Large cleanups take time.” After full environment copies, especially into sandboxes, admins needed to remove large volumes of non-essential data before follow-up work could begin. 

These themes shaped the updates now reaching general availability. 

What’s new 

1. Error handling and run visibility 

Every bulk deletion job now includes a Run details tab. Open a job and you’ll see a summary at the top — start time, end time, status, records deleted, records failed, and errors encountered. Specific errors are listed inline: 

• Completed — the job ran to completion but may have hit errors along the way. 

• Failed — the job never started; reasons are visible when you open it. 

Diagnose, fix the root cause, and move on without guessing.

 2. Solution-aware bulk deletion jobs 

Bulk deletion jobs are now solution-aware. Build and validate cleanup logic in development or sandbox, then move the same configuration to pre-production and production using standard solution export and import. The full job definition, filters, schedule, and name, travels with the solution. 

What this means in practice: 

• Configure once, promote everywhere. 

• No need to recreate jobs environment by environment. 

• Bulk deletion configurations follow the same lifecycle as the rest of your solution components. 

Step 1 – Go to maker portal, create a new solution and edit it to add an existing bulk delete job.

Step 2 – Go to Add existing> More > Other > Data Life Cycle Config to add an existing bulk delete job. 

Step 3 – Select the bulk deletion job to add to the solution.

Step 4 – With the bulk delete job in a solution, export the solution as you would for any other component. 

3. Permanent deletion checkbox in the Bulk Deletion Wizard 

Deleted records keeping is one of the most valuable safeguards for your business-critical data. As it moves from public preview to general availability, bulk deletion jobs in environments where deleted records keeping is enabled will copy records to the deleted records tables before removing them, giving you a recovery window if something is deleted in error. For data that matters to your business, that safety net is well worth the small amount of additional storage it uses.

That said, not every record needs to be recoverable once it reaches the end of its data lifecycle. Old system logs, expired workflow records, and transient telemetry are unlikely to ever be restored, yet keeping copies of them still consumes storage and adds processing overhead to every deletion job.

For exactly these situations, the new Permanent deletion checkbox in the Bulk Deletion Wizard lets you opt out of deleted records keeping for a specific job. When selected, it not only reduces the storage consumed by stale records, but also eliminates certain processing steps, which speeds up the deletion job itself.

The checkbox is available only for one-shot, non-recurring jobs, by design. Limiting it this way ensures admins make a conscious choice every time and avoids a scenario where a recurring job configured long ago keeps permanently deleting data without anyone realizing.

When Permanent deletion is selected:

• Deleted records cannot be recovered.
• No additional storage is consumed by deleted records.
• The bulk delete job runs faster.

Use it for non-recurring cleanup of data with a known expiration, the kind of data you would never need to restore anyway.

Caution: permanent deletion is exactly that. There is no undo. Verify the data targeted by your job is truly disposable before enabling this option.

4. Engine refinements and a new sandbox deletion mode 

We’ve made foundational updates to the Bulk Deletion framework, smarter record fetching, more efficient progress tracking, and refined thread management. These changes apply automatically; no configuration is required. 

For sandbox environments, particularly after a full production copy, we’ve introduced sandbox deletion mode. Enabled through the RunJobForSandbox option in the BulkDelete API, it: 

• Skips plug-ins, workflows, and deleted records keeping. 

• Uses the cascade engine directly. 

• Still respects cascade rules and referential integrity. 

This provides a leaner execution path for large-scale sandbox cleanup where business logic and recoverability are not required. 

Caution: Sandbox deletion mode is specifically designed for Sandbox. This deletion mode permanently deletes records with no recovery path, and plug-ins and workflows won’t fire. Use it only when the data is no longer needed and no business logic depends on delete-time events. 

Bulk Deletion keeps a Dataverse environment healthy

Bulk Deletion is the built-in way to keep a Dataverse environment healthy at scale, but it is only as effective as the data deletion jobs behind it. Schedule these recurring jobs from the day each table is provisioned and avoid letting transactional and log data accumulate. 

With the updates landing beginning June 2026, clearer run visibility, solution-aware portability, an opt-in permanent deletion path, and refinements to the underlying execution model — Bulk Deletion is more transparent to operate and easier to promote across environments. 

If you haven’t reviewed your data deletion jobs and data retention strategy in a while, now is a good time. 

Learn more 

• Delete bulk records — Power Platform | Microsoft Learn 

• Delete Data in Bulk to Reduce Storage Use — Power Apps | Microsoft Learn

• Restore deleted Microsoft Dataverse table records — Power Platform | Microsoft Learn 

The post Bulk Deletion in Microsoft Dataverse: New Capabilities for Data Lifecycle Management appeared first on Microsoft Power Platform Blog.

The Problem with Agentic Administration Today 

You’re managing 20 Dataverse environments. A security team asks you to enforce settings everywhere. You open the Power Platform admin center, click through the environment list, enter settings for each one, repeat 20 times. Or you wait for a script engineer to define a bulk delete flow for stale records. Hours of work that a computer should have done in seconds. 

That gap between intent and execution is where agentic administration lives. And it’s now available. 

What is Dataverse Admin Skills?  

Dataverse Admin Skills brings Dataverse environment administration into your coding tool through two paths: 

• Primary path: Agentic (natural language). You describe what you want in plain English. The Dataverse Skills Plugin (which includes dv-admin, dv-data, dv-query, dv-metadata, dv-solution, and more) runs inside Claude Code or GitHub Copilot. It translates your intent into the right PAC CLI commands (pac org, pac data, pac admin, pac auth), executes them against the Dataverse Web API, and handles everything from org settings and OrgDB toggles to bulk delete, retention, recycle bin, and security. The plugin enforces a 37-toggle Power Platform admin center (PPAC) allowlist and built-in safety guardrails, including confirmation prompts and multi-environment parallel execution. 
• Optional path: Direct scripting. The same PAC CLI commands that power the agentic path are available for Bash, PowerShell, or SDK scripts. Use this for CI/CD pipelines, runbooks, or any automation where you want repeatable, programmatic control. 

Both paths hit the same trusted PAC CLI (v2.6+, .NET Framework) and Dataverse Web API. The agentic path adds natural language understanding, multi-environment discovery, and safety checks on top.

Try this Prompt: “Enable AllowMCP setting on all environments starting with Preprod” 

The agent responds: 

1. Lists your Dataverse environments 

2. Filters for environments starting with “Preprod” 

3. Asks you to confirm the list 

4. Updates each environment in parallel 

5. Shows you a summary table of what changed 

One sentence. No browser tabs. No scripts to write. 

What’s Available Now and Coming Soon

• Settings Management. Read and update 37 allowlisted Power Platform admin center (PPAC) toggles across environments: MCP, audit, retention, recycle bin, search, Fabric, security, and more. Single environment or bulk, with parallel execution. 
• Bulk Delete. Schedule, list, pause, resume, and cancel bulk delete jobs. Built-in safety: confirmation prompts before destructive operations, FetchXML validation, and system table warnings. 
• Long-Term Retention. Enable retention on entities, define archival criteria with FetchXML, and monitor retention jobs. Move old records to long-term storage without permanently deleting them, ideal for compliance scenarios. 
• Capacity Management (coming soon): storage breakdowns, growth trends, capacity alerts, and archival recommendations, all from your coding tool. We’ll share these scenarios as they become available. 

Get Started and Try it out in three simple steps

Step 1: Install the plugin 

GitHub Copilot (VS Code):

 /plugin install dataverse@awesome-copilot

Claude Code: 

/plugin install dataverse@claude-plugins-official

Step 2: Try it 

• Open your coding tool and ask: 
• List all my Dataverse environments 
• The agent will install PAC CLI if needed, authenticate you, and return your environments. If anything is missing, it walks you through it. 

Step 3: Test the scenarios 

Settings management: 

• “Is auditing enabled on my dev environment?” 

• “Enable auditing on all my developer environments” 

• “Show me plugin trace log settings across all my environments” 

Bulk delete: 

• “Delete all email records created before January 1, 2024” 

• “Show me all bulk delete jobs on my environment” 

• “Pause the bulk delete job with ID …” 

This is the initial public preview release. We are continuously refining and expanding skills, so keep checking for updates. Learn more:

• Dataverse Plugin in Claude Marketplace Blog: Dataverse Plugin Is Now on the Claude Marketplace | Power Platform Developer Blog
• Dataverse Skills Blog: Dataverse Skills: Your Coding Agent Now Speaks Dataverse | Power Platform Developer Blog
• Dataverse Skills GitHub: Eight Dataverse Skills available today

The post Agentic Administration: Dataverse Admin Skills now available in Public Preview appeared first on Microsoft Power Platform Blog.

What are Monitor Alerts?

Monitor alerts allow tenant and environment administrators to proactively monitor the operational health of their Power Platform resources and receive notifications when health metrics fall below thresholds they define. Instead of learning about problems from end users, admins can identify and address issues before they cause disruption. This reduces downtime and improves reliability across the organization.

What’s New with GA

Predefined alerts — protection with zero configuration

The biggest addition we’ve added is predefined alerts: a set of configured, Microsoft-authored alerts that are enabled by default for every tenant. These alerts automatically surface high-use canvas apps, model-driven apps, agents, desktop flows and cloud flows whose health has dropped below recommended baseline thresholds — with no setup required.

For example, predefined alerts will flag when:

• The availability of high-use canvas apps drops below 90%
• The availability of high-use model-driven apps drops below 90%
• High-use cloud flows are experiencing success rate degradation

Predefined alerts give admins an immediate signal on what matters most in their tenant, even before they’ve configured a single custom alert rule. Items can trigger these alerts regardless if they’re in a managed environment, and predefined alerts will encourage users to create their own alert rules to monitor these items against their own custom thresholds.

Redesigned Monitor overview page

We redesigned the Monitor overview page to be alerts-centric. When you land in Monitor, you now get an at-a-glance view of active alert conditions and resource health across your environments — making it faster to identify what needs attention and act on it.

Code app alerts

Custom alert rules now support alerting on your code apps in addition to canvas and model-driven apps. This gives admins deeper visibility into code app performance and the ability to catch performance degradation before it affects users’ day-to-day experience.

Work queue alerts (public preview)

Admins can now configure alerts for Power Automate work queues in Monitor, enabling proactive monitoring of work queue health alongside apps, flows and agents. This capability is launching in public preview alongside alerts GA.

How Monitor Alerts Work

Admins define threshold-based rules on Monitor metrics. For example, this can look like receiving an alert when a cloud flow’s success rate drops below a custom threshold, or when a canvas app’s availability falls below an acceptable level.

Monitor alerts evaluate alert rules daily after aggregating new metric data for your environments. When a metric breaches a threshold, admins receive an email notification with a direct link to the details that triggered the alert.

You can scope alert rules to an environment or individual item, configure multiple recipients per rule (including security groups), and manage all active rules and review triggered alert history from the Alert Rules view in Monitor.

What’s Supported

We’re excited for you to improve the operational health of your apps, agents and automations in Power Platform. Learn more about Monitor and how to create alerts here.

The post Power Platform Monitor Alerts Are Now Generally Available appeared first on Microsoft Power Platform Blog.

What came through clearly in that conversation is that most organizations aren’t struggling to adopt agents because the technology is unsafe. They’re struggling because their governance models were built for a world that no longer exists. 

While traditional security models still depend on a clear distinction between “inside” and “outside,” and that boundary absolutely still matters. What’s changed is the pace. Agents now move fluidly across apps, data sources, and workflows often spanning environments that were designed with autonomous or semi-autonomous systems in mind.

When building an agent or app can take minutes, imposing governance models built around week-long and manual review processes quickly break down. The challenge isn’t whether to govern—it’s how. Governance has to account for blurred boundaries and apply the right oversight so teams can move fast, without losing control. 

When governance strategies boil down to “lock everything down” or “we’ll figure it out later,” the outcome is predictable: either uncontrolled adoption or shadow IT with no visibility. Neither is a win. 

The governance questions every AI agent should answer

The most effective organizations aren’t trying to stop agents. They’re figuring out how to classify risk clearly and apply the right controls at the right time. 

If governance is just a list of things people can’t do, that’s not governance—it’s a backlog of workarounds waiting to happen. Disruptors and innovators always find a way – whether it’s inside the system or outside your line of sight. When there’s no supported path to do the right thing, shadow IT isn’t a failure of discipline, it’s the natural result. Constraints without alternatives don’t stop innovation, they just push it underground, encouraging shadow IT. 

Real governance sets boundaries that let teams move fast and stay safe: 

• What data sources an agent can access 

• How broadly can it be deployed or shared 

• What actions is it allowed to take 

• What identity does it run under 

• What level of oversight applies as risk increases 

A low-risk personal productivity agent is not the same as an agent connected to a core business system. Treating them as if they are leads to predictable points of failure. You either over restrict everything and stall innovation, or you under-protect what actually matters, leaving critical systems exposed. Governance only works when it reflects the real differences in risk. 

Risk isn’t binary—and AI governance needs a risk-based model

A practical way to make this operational is a simple risk-based model. Not theoretical. Operational. 

Think in terms of graduated risk zones: 

• Low risk: constrained, self-serve scenarios where people can build and use agents with tight guardrails—limited data access, limited sharing.  In this scenario, makers don’t need to open a ticket for every idea, and IT doesn’t have to micromanage. Teams can move quickly, building with confidence, without friction, and IT can stay out of the critical path,  

• Medium risk: broader sharing, more sensitive data, more meaningful actions. These scenarios trigger review and oversight—but without resetting momentum or forcing heavyweight governance on every idea. 

• High risk: business critical workflows tied to core systems. These need deliberate control from day one. Not “nobody can build,” but “the right people build inside the right boundaries, with the right oversight.” 

The point isn’t the labels. The point is clarity. Risk is contextual. Governance should be too. 

Where governance actually gets enforced: the platform

Governance only works when it’s enforced inherently by the platform, not layered on through policy decks, emails, or spreadsheets. 

That’s why a concept of managed platform matters: Make security, governance and operations part of the platform experience—inventory, usage insight, controlled sharing, connector governance, and lifecycle management—rather than an external process held together by best intentions. 

Managed environments—our practical adoption of the managed platform concept—are a Power Platform capability, not something limited to a single product or workload. Managed environments enable teams to manage apps, automations, pages, and even agents built in Microsoft Copilot Studio 

One of the cleanest controls is also one of the simplest: sharing limits paired with a clear on‑ramp. 

If someone builds something for themselves or for their immediate teammates, that’s one risk profile. If they want to share their solution more broadly, that’s a different one. The platform needs to distinguish between those cases. When it does, you can let people experiment freely—and require deliberate promotion, review, and accountability when something is ready to scale. 

Agents don’t create permission problems—they expose them 

This bears repeating, because it matters: agents generally operate as the calling user. They don’t magically gain new permissions. Which means agents don’t create access problems; they expose the ones you already have, faster. 

If users have overly broad permissions today, agents will too. That’s not an agent problem—it’s an identity and access discipline problem. Effective agent governance only works when it’s built on solid foundations. 

Trust by design, with verification built-in 

Strong proactive controls matter, but they’re not enough on their own. You still need reactive controls: monitoring, diagnostics, and audit trails, especially when agents take actions with compliance implications. 

Trust but verify still applies. Looking at the familiar expense-approval analogy: humans unintentionally approve things incorrectly all the time. We manage that risk with audits, compensating controls, and limits on blast radius. Agent risk should be treated the same way: know what happened, understand why it happened, and contain the impact when it doesn’t go as planned. 

The takeaway 

The future isn’t “agents everywhere with no control,” and it’s not “no agents because risk.” Both fail. 

The practical path is adaptive governance: classify risk clearly, enforce it through the platform, and create promotion paths so good ideas can scale without turning into tomorrow’s incident response. 

That’s how organizations stop playing defense. If you want to learn how you can start saying “yes” safely, please watch the full interview with Fernando. 

The post ​Building trustworthy AI: A practical framework for adaptive governance appeared first on Microsoft Power Platform Blog.

Data is the center of every organization. With millions of records deleted daily—whether through routine clean-ups, app usage, or retention policies—the risk of accidental or malicious data loss is real and costly. Lost data can disrupt operations, impact compliance, and harm reputation. 

To prevent this, we are excited to announce that the capability to restore deleted table records in Microsoft Dataverse in General Availability starting late April 2026 with additional enhancements based on feedback from customers and MVP community. Organizations have the assurance that they can recover from unforeseen data loss without disruptions, ensuring business continuity and customer trust. 

How Data Loss Happens 

Records can be deleted from multiple sources and understanding these data loss scenarios is essential: 

• Custom apps used by end users. End users often interact with apps directly, and accidental deletions can occur during everyday tasks.  

• Makers building solutions. Makers frequently experiment and iterate while creating apps and flows. During this process, records may be deleted unintentionally. 

• Admins running bulk delete jobs. Admins schedule clean-up jobs to optimize performance and storage. However, these automated jobs can sometimes remove data that later proves necessary. 

• Retention policies moving old data to managed data lakes. Older data moved to cold storage optimizes performance and reduces costs. However, restoring from cold storage can be slow and complex.  

Consistent Deleted Records Keeping 

Previously, deleted records keeping settings could vary by table, creating complexity for admins and uncertainty for users. For example, in environments with parent-child relationships, partial keeping of deleted records often meant incomplete recovery—leading to operational risks. 

To eliminate this complexity, deleted records keeping is now managed at the environment level. Admins can enable or disable deleted records keeping for all tables in an environment with a single setting by going to feature management.  

This change ensures: 

• Consistency: No more guessing which tables are covered. Every table in the environment follows the same deleted records keeping policy, reducing confusion and ensuring predictable outcomes. 

• Reliability: Full recovery of related records. Parent and child records are kept together, eliminating partial recovery scenarios and safeguarding data integrity. 

• Simplicity: Reduced administrative overhead. One setting replaces multiple table-level configurations, saving time and reducing the risk of misconfiguration. 

This streamlined approach to deleted records keeping turn a fragmented setup into a consistent, organization-wide safeguard. 

Admins with Full Control and Visibility 

With this update, admins in Power Platform Admin Centre (PPAC) gain complete authority over deleted record keeping and clean-up, along with clear visibility into storage usage: 

Optimize with Confidence

Admins can manage deleted record keeping periods (up to 30 days). Admins can make informed decisions to balance data safety with storage efficiency, tailoring deleted records keeping period to business needs.

Flexible Clean-Up Options

Admin can use the new “Delete All Records” button for quick purges or selectively delete records for granular control. Whether performing routine maintenance or responding to urgent storage constraints, admins have the tools to act swiftly. 

Visibility into storage used by deleted records 

Admins can now view the storage consumed by deleted records, enabling informed actions to manage database capacity. 

This approach not only empowers admins but also transforms deleted records keeping management into a strategic advantage—balancing data safety with cost efficiency and operational clarity. 

Business Benefits

These improvements aren’t just technical changes—they deliver tangible business benefits: 

• Reduced risk. Protect against accidental or malicious deletes with a reliable safety net. 

• Operational resilience. Restore critical data quickly to maintain continuity and avoid downtime. 

• Simplified governance. One setting for all tables means fewer surprises and easier compliance. 

With Dataverse, your organization gains a dependable safety net and the flexibility to stay in control of its data. To learn more:  

• Restore deleted Microsoft Dataverse table records – Power Platform | Microsoft Learn 
• Restore deleted records with code – Power Apps | Microsoft Learn 

The post Safeguard, Restore, and Manage Deleted Records in Microsoft Dataverse appeared first on Microsoft Power Platform Blog.

In a recent conversation I had with Dion Hinchcliffe at Futurum, we spent time unpacking a shift I’m seeing consistently across enterprises experimenting with AI. It’s not just about copilots or chat interfaces. It’s about something deeper: a change in how work is designed, governed, and operated when systems can reason and act with intent.

For decades, applications have been the primary interface between people and systems. Work meant navigating menus, filling out forms, and clicking through screens carefully designed to constrain what users could do. Productivity improvements came incrementally—better layouts, faster load times, and more automation behind the scenes—but the underlying engagement model stayed the same. People adapted to software.

That model no longer holds.

As organizations race to adopt AI, a new challenge is becoming clear: translating human intent into systems that can act autonomously—without sacrificing control, security, or trust. Intent-first development addresses that gap by reshaping how agentic applications are designed, governed, and delivered at scale.

Agents as the new interaction layer

Instead of teaching people how to use systems, we can let people express intent—and allow systems to determine how that intent is carried out. This is not about replacing all apps overnight. It’s about changing their role. Apps no longer need to expose every possible action through UI. Instead, they:

• Provide trusted capabilities the agent can invoke
• Enforce business rules and permissions
• Act as systems of record, not systems of navigation

As AI systems become capable of reasoning, acting, and adapting, organizations are beginning to rethink the relationship between humans and software. In an agentic model, the agent becomes the primary interaction surface. A user may no longer need to know which system to open or which workflow to follow. They can simply state what they want to achieve: open a purchase order (PO), resolve this case, prepare a customer briefing.

Behind the scenes, agents orchestrate the necessary steps across systems, policies, and data sources. Procurement rules are applied. Approvals are routed. Records are updated. The user expresses intent once; the system coordinates the work.

Agentic solutions aren’t eliminating applications, but they are changing how people engage with them. Apps are the trusted capabilities agents rely on—serving as systems of record, sources of authority, and enforcement points for business rules and permissions. Applications shift from user destinations to services agents invoke. Agents work because structure already exists.

Rethinking enterprise complexity: Orchestration over navigation

This shift becomes clearer when you look at everyday enterprise processes.

Take something as common as opening a purchase order. Today, that often means navigating multiple tools, involving several teams, and manually coordinating approvals. The complexity isn’t the work itself—it’s knowing how to move through the systems.

With an agent‑first approach, that complexity is inverted. A user can simply say they need to open a PO for a project. The agent determines which background agents are required—vendor management, policy validation, approvals—and orchestrates the process across systems without forcing the user to navigate them.

We see the same pattern emerging in CRM. Rather than sales teams manually updating records, agents can monitor emails, calls, calendars, and systems in the background—keeping data current and surfacing relevant context proactively. The agent becomes the interface to customer intelligence, while the CRM remains the authoritative store behind it.

The value here isn’t conversational UI for its own sake. It’s reducing cognitive load while preserving control.

Agents as the business logic and decision layer 

This shift also changes where business logic lives.

Traditional enterprise systems embed logic deep inside individual applications—rules, workflows, and decision trees hardcoded into each tool. That makes change expensive and reuse difficult. When requirements evolve, logic must be rewritten repeatedly across systems.

Agentic systems invert that model. Logic moves into a shared reasoning layer that sits above systems of record. Agents evaluate intent, context, and constraints, then determine which actions are required right now. Policies, best practices, and exceptions can be defined once and applied consistently across processes instead of being repeatedly embedded in individual applications.

This is where the economics of software start to change. Improvements to reasoning or decision quality can compound across organizational functions—HR, finance, operations, and customer engagement—without rebuilding each system individually. Business value shifts from static workflows to shared enterprise intelligence.

Headless agents as a new layer of digital labor 

Not all agents interact directly with people.

Many of the most impactful agents operate quietly in the background—monitoring systems, reacting to triggers, coordinating tasks autonomously. These “headless” agents update records, flag issues, generate reports, and escalate decisions only when human judgment is required.

Together, conversational and headless agents form a new layer of digital labor. Routine work is handled automatically. Humans stay focused on oversight, judgment, and exceptions. The agent doesn’t replace enterprise logic—it coordinates it.

Operating agentic systems at scale requires a control plane

One point Dion and I kept coming back to is this: the real challenge with agentic systems isn’t building the first one. It’s operating hundreds—or thousands—of them responsibly.

As agents scale across teams and geographies, the questions shift quickly. How do you maintain visibility into what agents are doing and why? How do you enforce security, policy, and compliance consistently as agents act across systems? How do you measure impact, cost, and effectiveness as usage grows?

Without a managed platform, intent first development becomes ungovernable at scale. Logic fragments. Visibility breaks down. Early experimentation turns into operational risk. Governance must mature alongside autonomy.

This is where enterprise readiness becomes decisive.

Governance, lifecycle management, observability, and control aren’t optional add‑ons. They’re the foundation that allows agents to operate safely and reliably. Successful enterprise adoptions hide complexity behind an interface that works the way people already think.  Agents don’t eliminate the need for structure—they depend on stronger, more explicit structure than traditional automation ever required.

From pilots to an enterprise operating model

Most organizations begin with pilots—and that’s the right place to start. But pilots stall when governance, ownership, and measurement are treated as afterthoughts.

The pilots that scale share common patterns: centralized policy management, clear accountability between IT and business teams, built-in monitoring, and an explicit path from experimentation to production. Governance isn’t what slows progress; it’s what gives leaders confidence to move faster.

Over time, this becomes more than a collection of use cases. It becomes an operating model. Work shifts from task execution to outcome driven orchestration. Processes move from periodic redesign to continuous optimization. Systems adapt as business intent evolves.

Building adaptive enterprise systems for an agent-first world

This shift isn’t about predicting the future. It’s about building systems that can adapt as it arrives.

Agentic transformation isn’t just a technical change. It’s an operational one—reshaping how work is designed, governed, and continuously improved across the enterprise. Organizations that invest early in the right foundations—clear intent, strong constraints, and disciplined scale—will be positioned to turn intelligent applications into a durable advantage, not a fleeting experiment.

The most successful organizations won’t ask how to bolt agents onto existing apps. They’ll ask how to redesign systems so agents can sit confidently at the front door—turning intent into action with trust, speed, and scale.

In an agent first world, applications remain systems of authority and agents simply coordinate how and when those capabilities are invoked. Apps evolve:

• From destinations → to services
• From user driven workflows → to agent orchestrated actions
• From “where work happens” → to “how work is made possible”

If you want to hear this thinking unpacked in more detail, I explore these ideas directly with Dion Hinchcliffe at Futurum—from agents as the new interaction layer, to why governance becomes more critical, not less, as autonomy increases. Our conversation gets into real enterprise examples, the challenges of moving beyond pilots, and what it actually takes to operate agentic systems at scale.

I encourage you to watch the full interview to hear how these concepts show up in practice and to learn how intent first development is shaping the future of enterprise AI.

The post From apps to agents: Rearchitecting enterprise work around intent appeared first on Microsoft Power Platform Blog.

Summary Welcome to the Power Platform monthly feature update! We will use this blog to share news in Power Platform from the last month, so you can find a a summary of product, community, and learning updates from Power Platform in one easy place. Now, let’s dive into what’s new in Power Platform:

Apps, agents and Copilot

Public preview: M365 Copilot chat in model-driven apps

Copilot chat is now available directly inside apps built with Power Apps, bringing the intelligence of Microsoft 365 Copilot into the flow of business processes.

This unified experience—currently limited to model-driven apps—lets users ask questions, reason over in‑app data, and connect insights from documents, communications, and collaboration—without leaving the application they’re working in. By embedding Copilot chat into low‑code apps, organizations can keep users in context and in flow, reducing app switching while accelerating decision‑making. Teams can also leverage powerful first‑party agents like Researcher and Analyst, as well as custom Copilot Studio agents, to analyze data, generate insights, and take informed action directly within their apps.

To manage Microsoft 365 Copilot chat for model-driven apps, start by learning how to manage Microsoft 365 Copilot chat. Power Platform administrators can set up and configure the Microsoft 365 Copilot chat feature for users in their environment and makers can then enable or disable Microsoft 365 Copilot chat for a specific model-driven app.

Public preview: Power Apps MCP and enhanced agent feed

We’re bringing Power Apps Model Context Protocol (MCP) Server and an enhanced agent feed into public preview. This is a step to enable better human-agent collaboration directly inside business applications with built‑in human supervision.

Power Apps MCP brings agentic features from apps to agents as tools – starting with data entry. Agents will be able to parse the unstructured data into forms that users use in apps and create records directly, as well as flag them for human review or action.

The enhanced agent feed provides a shared workspace for humans to oversee the agent activity—makers can provide granular visibility into agent actions for their users, use side‑by‑side comparison views for approvals, and direct navigation to in‑app records.

Building modern apps

Public preview: a new modern Card control

This new modern Card control helps makers build clean, responsive, and consistent UI layouts in canvas apps.

The modern Card control allows makers to present structured information—such as summaries, previews, and tiles—using a single layout‑aware control instead of composing multiple classic controls. Cards automatically adapt to vertical or horizontal layouts and align with Fluent UI design principles, improving visual consistency across apps.

By reducing layout complexity and improving responsiveness out of the box, the Card control enables faster UI composition while supporting accessibility and scalability across screen sizes.

Generally available: theme copy‑paste

With theme copy-paste it is it easy to reuse visual styles across canvas apps without manual reconfiguration.

Theme copy‑paste allows makers to copy and reuse a Canvas app’s theme—including colors, typography, and styling tokens—across other apps. These themes are copied as YAML which can also be edited manually by makers as text. This reduces repetitive setup and helps ensure consistent branding and visual identity across an app portfolio. 

By simplifying theme reuse, this update accelerates new app creation and supports design governance at scale, especially for teams managing multiple canvas apps across environments.

Generally available: confirm() function in canvas apps as a fluent dialog

The Confirm function displays a modal confirmation dialog over the current canvas screen, prompting the user to explicitly confirm or cancel before continuing. In canvas apps, there’s also a dismissal path (for example, clicking outside the dialog) that is treated as no action and returns blank.

The canvas experience is designed to align with Fluent dialog behavior and to respect the current app theme. You need to have modern controls turned on to get fluent dialog, else you will get a browser native dialog.

Managed platform

Public preview: move canvas apps and custom SharePoint forms out of the default environment

The default environment in Power Platform often becomes a shared space where makers build and test applications, leading to potential challenges with governance and organization. As resources accumulate in this environment without structured oversight, administrators may face difficulties managing security policies, tracking ownership, and maintaining compliance across their tenant.

We introduced a recommendation in Power Platform advisor, as a preview, that enables administrators to migrate certain canvas apps and custom SharePoint forms from the default environment to designated managed environments. The migration can be done manually from the Recommendations page under the Actions menu in the Power Platform admin center or automated using the Power Platform for Admin v2 Connector. When moving apps, administrators can choose to keep the original resource as is or restrict access to it by quarantining, or deleting it entirely.

This helps Power Platform administrators in implementing effective governance and DLP controls and establish clearer boundaries for app development.

Generally available: host and run code apps in Power Apps

We’re excited to announce that code apps in Power Apps are now generally available, empowering developers and IT alike at a moment when organizations are building more custom applications than ever. With the rise of AI‑accelerated and code‑generation‑assisted development, teams can build high‑quality web apps faster than before while IT faces mounting expectations around governance, security, and operational oversight. Code apps bridge that gap by giving developers full code‑first flexibility and giving IT the enterprise‑grade guardrails needed to manage a growing app landscape

Power Apps code apps bring the full strength of Power Platform to web developers. Build with popular frameworks (React, Vue, and others) in any code-first IDE, and deploy to Power Apps. Every code app automatically becomes a governed Power Platform asset, giving IT visibility and control without creating friction for developers. 

Learning updates

Training paths and labs

Updated training

• Create and customize sites with Power Pages design studio – Training
• Explore Power Pages design studio data and security features – Training
• Explore Power Pages templates – Training

Power Apps maker

New

• Use preview tools and upcoming features in Dataverse MCP server
• Use modern themes in canvas apps  

Updated

• Create or edit model-driven app web resources to extend an app
• Generate a page using natural language
• Overview of pipelines in Power Platform
• Admin deployment page
• Use table segmentation in solutions
• Add Microsoft 365 Copilot chat for app user in model-driven apps
• Overview of the new Power Apps vibe experience
• Create apps, data, and plans together using Power Apps vibe
• Card modern control in Power Apps
• Keyboard shortcuts for canvas apps
• Sign in to Power Apps

Power Platform administration

New

• Move apps from the default environment (preview)

Updated

• Virtual Network support overview
• Set up virtual network support for Power Platform
• Automatic deletion of Power Platform environments
• Microsoft 365 environment for recurring Copilot prompts
• Preview and experimental AI models
• Export data to Application Insights
• General availability deployment
• PowerShell support for Power Apps and Power Automate
• Environment routing
• Manage Copilot Studio credits and capacity
• Buy Power Automate licenses
• Restore deleted Microsoft Dataverse table records (preview)
• Dataverse capacity-based storage details
• Configure Dataverse search for your environment
• Track, manage, and scale Copilot adoption in the Power Platform
• Content security policy
• Continuous access evaluation (preview)
• Power Platform inventory
• Finance and operations storage capacity
• Permissions and roles for SharePoint document management tasks
• Allow external language models for generative responses
• View and manage on-premises data gateways
• System Settings Service tab
• Administrator analytics and reports for Microsoft Power Apps
• Microsoft Power Platform admin documentation
• Power Platform inventory API
• Discover what drives engagement in the Power Platform by using the Usage page
• Configure email resolution with the DoNotResolve flag
• Licensing and AI Builder credits
• Licensing and Copilot Credits
• End of AI Builder credits
• Workflows agent privacy and data subject request (DSR) FAQ

Power Platform developer

New

• Web API Query Data Sample (PowerShell)
• Web API Conditional Operations Sample (PowerShell)
• Web API Functions and Actions Sample (PowerShell)
• dataApi reference for generative pages
• RetrieveTimeZone sample (C#)

Updated

• Power Apps code apps overview (preview)
• How to: Connect your code app to data (preview)
• How to: Connect your code app to Dataverse (preview)
• navigateTo (Client API reference) in model-driven apps
• How to: Configure Content Security Policy (preview)
• Generate a page using natural language with model-driven apps in Power Apps
• Microsoft Power Platform CLI auth command group
• Dataverse SDK API Reference
• Microsoft Power Platform API reference

Power Apps user and mobile

Updated

• How mobile offline works in Power Apps
• Use Microsoft 365 Copilot chat in model-driven apps (preview)
• Optimize the offline profile
• Set up mobile offline for canvas apps
• FAQ for Dataverse search
• What is Dataverse search?
• Visualize data in a view with Copilot (preview)
• Customize and build your mobile app using the wrap wizard
• Prevent canvas app restarts in the Power Apps mobile app
• Check user access to a row
• Use Copilot’s form fill assistance feature in model-driven apps
• Use Copilot chat in model-driven apps
• Modern, refreshed look for model-driven apps
• Supervise agents in model-driven apps with agent feed

Power Pages

New

• Connect Power Pages server logic to Azure Function
• Power Pages Server Logic Debugging Guide

Updated

• Create an event registration page
• How to interact with Dataverse tables using server logic
• Power Pages server logic overview (preview)
• Advanced Settings (preview)
• Create and deploy a single-page application in Power Pages
• Set page permissions
• Security agent (preview)
• Add Copilot summarization to case page (Preview)
• Configure Omnichannel with Power Pages site agent
• Edit code with Visual Studio Code for the Web (preview)
• Use the Visual Studio Code extension
• FAQ for site search with generative AI
• Set up Microsoft Entra External ID with Power Pages

The post What’s new in Power Platform: February 2026 feature update appeared first on Microsoft Power Platform Blog.

With this preview, Microsoft Power Platform admins gain a clearer view into what drives engagement, which resources create the most impact, and where to focus efforts to accelerate adoption and value across the platform. To explore the experience, visit the documentation or simply head to the Power Platform admin center, select ‘Manage’ in the left navigation, and click on ‘Usage’ to bring up the new experience.

Why we built the new usage page

We heard customers’ feedback and requests for a reliable, unified view of usage across the platform. Organizations depend on Power Platform to accelerate digital transformation – and now, with the usage experience, they can:

• Understand adoption patterns
• Identify top-performing solutions
• Detect emerging opportunities or risks

The new usage page consolidates usage metrics across Power Apps, Power Automate, and Copilot Studio, giving admins a single pane of glass to see how apps, agents, and workflows are built and used in their organization.

What’s included in the public preview

During public preview, admins get access to a view featuring:

Summary view

A high-value snapshot of how your organization is engaging with the platform:

• Adoption over time – Track daily active usage over the last 28 days
• Usage by product – View aggregated usage across:
  • Power Apps → Active users launching apps
  • Power Automate → Flow runs
  • Copilot Studio → Agent sessions
• High-value resources – Quickly identify the top three apps, flows, and agents driving adoption

Detailed resource tables

Interactive, sortable tables let you explore usage trends across individual items, making it easy to identify which items are driving the most usage. The following item types are supported across Power Apps, Power Automate, and Copilot Studio:

• Power Apps – Canvas and model-driven apps
• Power Automate – Cloud flows
• Copilot Studio – Agents built in Copilot Studio

These tables help admins pinpoint trends, track growth, and troubleshoot issues at the resource level.

Get started today and shape the product

Visit the Learn documentation on usage page or go straight to your Power Platform admin center → Manage → Usage to learn more and explore the new Usage view.

We look forward to hearing how you use these insights to help your organization grow adoption and unlock even greater value with the Power Platform. And we’ll be continuing to build on this unified view leveraging your feedback – so don’t hesitate to share it with us.

The post Announcing the public preview of the new usage page in the Power Platform admin center appeared first on Microsoft Power Platform Blog.