This release brings a significant advancement in how external user access is secured and managed. Authorization is now enforced directly within Dataverse, providing stronger security, improved visibility, and more precise control while keeping the maker experience unchanged. This feature currently needs to be enabled at a website level.

What’s new in this release

Authorization enforced directly in Dataverse

Access decisions are evaluated where the data resides, ensuring consistent enforcement of security policies across all access scenarios and strengthening overall data protection. This helps reduce security gaps and ensures a more reliable access control framework.

Improved audit visibility of external users

Audit logs now reflect the actual external user performing actions. This enhances traceability, simplifies compliance reporting, and provides clearer operational insights. It also enables teams to investigate issues faster and maintain stronger accountability.

Column-level security support

Protect sensitive data with greater precision. Column security profiles allow you to control not only which records users can access, but also which specific fields are visible or editable. This ensures sensitive information is exposed only to the right users when needed.

Learn more: Column security profile (preview)

Custom Scope for granular access control

Introducing Custom Scope, enabling fine-grained, row-level access control based on business conditions. This allows you to define exactly which records each user can access, beyond traditional access models. It gives you greater flexibility to model real-world access scenarios with precision.

Learn more: Custom access type (Preview)

Seamless experience for makers

There’s no need to redesign your applications. Makers can continue using familiar Power Pages constructs while benefiting from stronger, platform-level enforcement behind the scenes. This allows teams to adopt enhanced security without impacting productivity or development workflows.

How it works (at a glance)

Native Dataverse Authorization brings Power Pages security closer to the Dataverse model through a simple alignment of concepts.

At a high level:

• Contacts are represented as Dataverse users: Each external user is represented within Dataverse, enabling access to be evaluated in a true user context.

• Web roles align with security roles: Roles defined in Power Pages align with Dataverse security roles, ensuring consistent role-based access control.

• Operations run in user context: All operations execute in the context of the signed-in user rather than a shared application identity, ensuring access is consistently enforced based on user permissions.

What to be aware of
If you have existing plugins or custom logic registered on Dataverse tables, they will now execute using the calling user’s permissions. In some cases, this may surface access-related errors where actions previously succeeded with elevated privileges. We recommend reviewing and validating such customizations to ensure they align with user-level access.

Getting started

Enable Native Dataverse Authorization in your Power Pages site and start exploring these enhancements:

• Enable enhanced authorization (preview)
• Column security profile (preview)
• Custom access type (Preview)
• Audit logging

We are looking forward to your feedback

Your feedback is crucial in shaping the future of this feature. We want to hear from you!

The post Native Dataverse Authorization (Public Preview) for Stronger Security in Power Pages appeared first on Microsoft Power Platform Blog.

Dataverse Plugin for Coding Agents: Marketplace Expansion 

The Dataverse plugin for coding agents brings the full power of Microsoft Dataverse directly into the developer’s coding environment. Instead of switching between browser tabs, documentation, and admin portals, developers can describe what they want in natural language and the plugin handles the rest. It intelligently routes each request through the right tool, whether that’s the Dataverse MCP server (see latest update), the Python SDK, PAC CLI, or the Dataverse CLI, so developers stay in flow and get production-grade results without needing to master every tool individually. Built on an open-source skill architecture, the plugin enforces least-privilege security, follows documented auth patterns, and respects existing Dataverse RBAC, making it safe for real enterprise environments from day one. See the Dataverse plugin for coding agents in action here.  

We are excited to announce the expansion of the Dataverse plugin into additional coding agent marketplaces, meeting developers where they already work. The plugin is now available for Claude, Cursor and GitHub Copilot. This means that whether a developer’s primary coding agent is GitHub Copilot, Claude or Cursor, they get the same Dataverse expertise: intelligent skill routing, enterprise-grade guardrails, and a consistent natural-language experience across every surface. This cross-platform availability reflects our commitment to making Dataverse accessible wherever agents are being built, and we will have support for more coding agents coming soon. 

A Growing MCP Ecosystem Connected to the Systems You Already Run 

Model Context Protocol (MCP) servers give agents a common way to discover and use tools across systems: one standard connection model that helps any agent work with the right tool, in the right system, at the right time. Microsoft is building a rich MCP catalog designed around the systems enterprises already depend on — from productivity and developer experiences to business applications and partner platforms.

The catalog includes 60+ ready MCP servers, and the customer promise is simple: start faster with ready-to-use MCPs, connect agents to familiar business systems, and use the same standard across Microsoft 365 Copilot, Copilot Studio, Azure AI Foundry, GitHub Copilot, and other MCP-compatible experiences. For example, the Dataverse MCP server is natively supported today in Copilot Studio, Azure AI Foundry, and other MCP-compatible clients. 

Certified MCPs: ISV Built MCPs that Customers Can Discover, Trust, and Govern 

For ISVs and partners, MCP certification creates a trusted route into the Microsoft ecosystem. Once certified, partner-built MCPs become easier for customers to discover, evaluate, and adopt, while signaling that the experience aligns with enterprise expectations around security, governance, and observability. For customers, certified MCPs help reduce uncertainty: they can look to a growing ecosystem of partner capabilities designed to extend agents into specialized business scenarios, with clearer trust signals and a path toward governed adoption at scale. 

1. Package your MCP for certification. Prepare a certification package that includes your MCP manifest (with the MCP endpoint URL), Tools JSON file, and Key Vault-backed authentication details for securely managing secrets. 

2. Choose your certification offer type. Select the appropriate certification offer type ‘Apps and Agents for M365 and Copilot’ for your MCP and submit the package through Partner Center to make your MCP available across Microsoft agent experiences. 

3. Publish across Microsoft experiences. Once certified, your MCP becomes available for customer adoption across supported Microsoft surfaces, including Copilot Studio and Azure AI Foundry, making it easier for customers to discover, trust, and use your MCP in enterprise AI solutions. 

Bring Your Own MCP: Your Internal Tools, Governed Like the Catalog  

Beyond the rich MCP catalog, Bring Your Own MCP enables organizations to connect their unique business systems and workflows to the agent ecosystem. If your organization has a custom tool, proprietary API, internal workflow, or industry-specific system, you can bring that MCP server into your own organization and make it available for agents under enterprise controls. The goal is to give customers flexibility without giving up governance: register the MCP once, make it discoverable for the right agent scenarios, and manage it with the same expectations for admin approval, visibility, and control. 

Dataverse agentic evolution: from experimentation to execution  

As AI becomes a coding partner, Dataverse gives makers and developers the trusted data platform to build apps and agents faster, with the business context, connected tools, and enterprise governance needed to move from experimentation to execution. Learn more:  

Dataverse MCP: Dataverse MCP Server: Understanding the New Tool Shape – Microsoft Power Platform Blog

Dataverse MCP preview docs: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/data-platform-mcp-preview-tools 

Dataverse Plugin on Claude Marketplace announcement blog: https://devblogs.microsoft.com/powerplatform/dataverse-plugin-claude-marketplace/ 

For ISVs and partners, check out the MCP certification to creates a trusted route into the Microsoft ecosystem

Read the Bring Your Own MCP docs

Dataverse docs: https://learn.microsoft.com/en-us/power-apps/maker/data-platform/data-platform-intro 

The post Dataverse Is Your Agent Data Platform: Here’s What’s New in July 2026 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 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:

Agentic apps

Power Apps MCP server introduces closed-loop learning for enterprise agents

Enterprise AI has made building agents faster than ever. But teaching those agents how your organization works still means feeding knowledge in as documents and custom instructions or standing up a data science team to run the training, evaluation, and optimization cycles yourself. For IT leaders running agents at scale, that’s a ceiling on how much institutional knowledge your systems can hold, and an overhead that grows with every agent you add.

We introduced closed-loop learning for agents connected to the Power Apps MCP server, starting with the data entry tool. Every correction a user makes through the agent feed persists as structured memory. On future runs, the agent retrieves that memory and applies it. Over time, those corrections consolidate into organization-wide patterns the agent applies across tasks. The feedback loop runs automatically in production. Nothing to configure, no data pipelines to build.

AI powered development

Release planner code app: Explore Microsoft release plans with Power Apps code apps

The Power CAT team has released a sample application called the ‘release planner code app’, built using Power Apps code apps, React, and custom connectors that helps users explore Microsoft’s release plans across Power Platform, Dynamics 365, and Microsoft Copilot.

The app provides a modern experience to search, filter, and track upcoming features by product, release wave, cloud availability, and release status. Users can view release plan items in card, calendar, and timeline views, helping makers, developers, architects, administrators, and business users stay informed about Microsoft’s latest investments.

The sample demonstrates how developers can use Power Apps code apps to build enterprise-grade experiences while integrating external APIs and modern web development patterns.

Power Automate

Compare desktop flow versions side by side with built-in version control

Power Automate for desktop now includes version comparison as part of built-in version control, making it easier for makers to understand exactly what changed between two versions of a desktop flow. Teams can compare versions side by side across subflows, actions, variables, UI elements, and images, and use search within the comparison view to quickly locate specific changes.

This capability builds on the version control experience for desktop flows, where makers can save drafts, publish stable versions, review version history, and restore earlier versions when needed. With versions stored in Microsoft Dataverse and retained for up to 12 months, organizations get a more structured and governed way to manage changes across the lifecycle of desktop automations.

Public preview: Launch a Power App directly from a desktop flow with the new ‘run Power App’ action

The new ‘run Power App’ action lets desktop flows open a Power App directly and establish a native communication channel between the two experiences. Makers can pass inputs from the desktop flow into the app, capture outputs back into the flow, and trigger callable subflows from app events, unlocking richer attended automation scenarios without relying on UI-based workarounds.

This integration is especially useful for guided forms, app-based front ends for desktop automations, and event-driven experiences where user actions in a Power App determine what the desktop flow does next. Available in preview for Power Automate for desktop version 2.68 or later, the feature brings modern app experiences together with local automation in the same environment.

Managed platform

Generally available: Advanced connector policies

Copilot, agents, and AI-first projects have multiplied both the people who build and the places they build in. A tenant that had a few dozen environments two years ago can have thousands today. And what you need to govern is no longer just which connectors — it’s which actions and MCP servers inside them that AI tools utilize. Today, we’re making advanced connector policies (ACP) generally available to meet that moment.

Public preview: Power Platform inventory now shows the connectors and connector operations used by apps, flows, and agents in your tenant

Power Platform inventory has always shown admins what exists in their tenant. Now it shows what each resource talks to. Rolling out in public preview since June 2, inventory captures the connectors and connector operations used by every canvas app, model-driven app, cloud flow, agent flow, Microsoft 365 agent flow, and agent (authored in either Copilot Studio or Microsoft 365 Copilot Agent Builder). For flows, it also captures the trigger connector and trigger operation, and for agents it captures richer metadata about how each connector is used as a tool or knowledge source.

This unlocks a range of governance and IT scenarios: pinpoint every resource impacted by a connector deprecation, security issue, or licensing tier change in seconds; understand which connectors dominate adoption across the tenant; and ground advanced connector policy (ACP) — now generally available — decisions in real usage patterns so you know exactly which resources are affected before you tighten or block a connector. No action is required to opt in — connector data flows into inventory automatically.

In the Power Platform admin center, a new connectors column appears across the inventory grids — the unified manage > inventory page as well as the resource-specific views under Copilot Studio, Power Apps, and Power Automate — so you can see each resource’s connector footprint at a glance. The same data is queryable programmatically through the Power Platform for admins V2 connector, the Power Platform inventory API, and Azure Resource Graph, making tenant-wide analysis a single query rather than a manual project.

Learning updates

Training paths and labs

New

• Automate and extend your solutions with AI in Microsoft Power Automate
• Build intelligent apps and portals with Microsoft Power Apps
• Design AI-powered business solutions with Microsoft Power Platform
• Get started with AI-first solutions in Microsoft Power Platform
• Turn business ideas into Power Platform solutions with Plans

Updated

• Challenge project – Build applications and automation solutions
• Common command bar scenarios
• Configure exception and error handling in Power Automate desktop app
• Customize views and forms for model-driven apps
• Database handling in Power Automate desktop app
• Functional Consultant skills
• Get started with Power Automate
• Get started with security concepts in Dataverse
• Perform common actions with client script in Power Platform
• Use Monitor to troubleshoot Power Apps
• Use Power Automate desktop app to interact with windows and applications

Power Apps maker

Updated

• Add data connections to canvas apps
• Add Microsoft 365 Copilot chat for app users in canvas apps (preview)
• Add Microsoft 365 Copilot for app users in model-driven apps
• App ratings for Model-driven-apps | MicrosoftDocs
• Best practices for using the Gallery control in canvas apps
• Configure the Dataverse model context protocol (MCP) server
• Configure your environment and link to Microsoft Fabric
• Create a blank canvas app from scratch
• Create a canvas app based on Excel data
• Create a canvas app using Microsoft Dataverse
• Create a canvas app with data from a list
• Create an app to edit tables in canvas apps
• Create and edit canvas apps with AI code generation tools
• Create or edit a model-driven app system chart in Power Apps
• Create virtual tables using virtual connectors in Microsoft Dataverse
• Dataverse data in Microsoft 365 Copilot
• Delete a canvas app
• Design forms for performance in model-driven apps
• Enable your app and custom tools in Microsoft 365 Copilot
• Get started with formulas in canvas apps
• Grid container control in Power Apps
• Import solutions in Power Platform
• Importing and exporting data
• Improve component performance, stability, and reliability with solution checker
• Limitations and troubleshooting virtual tables with Power Apps
• Low-code plug-ins Power Fx
• Prompt columns in Microsoft Dataverse
• Save and publish canvas apps
• Set a preferred solution
• Setting up relationships with virtual tables with Power Apps
• Show items of different heights in a canvas app gallery
• Show, sort, and filter data in a canvas app gallery
• Streamline app development with low-code plug-ins in Microsoft Dataverse
• Types of tables
• Understand data sources for canvas apps
• Update a solution
• Use modern themes in Power Apps
• View the history of a solution
• What is Dataverse intelligence?
• Why choose Microsoft Dataverse?

Power Apps user and mobile

Updated

• Use keyboard shortcuts in Power Apps| MicrosoftDocs
• Use Microsoft 365 Copilot in model-driven apps
• View, compose and respond to email | MicrosoftDocs

Power Automate

New

• Export OCPM Semantic Model to Fabric Workspace (preview)

Updated

• Actions reference
• Automate using UI elements
• Classic designer vs. modern designer for cloud flows – Power Automate
• Configure desktop flow logs behavior
• Create a CyberArk credential
• Create and manage test cases for desktop flows
• Design flows with Microsoft Visio in Power Automate [DEPRECATED] | Microsoft Docs
• Governance in Power Automate for desktop
• Ingest an object-centric event log (preview)
• Ingest data from Fabric OneLake
• IP address configuration
• Manage cloud flow run history in Dataverse
• Power Automate v2 schema
• Testing actions
• Trigger desktop flows from cloud flows
• Trigger flows when a row is added, modified, or deleted
• Troubleshoot unattended desktop flow execution failures
• Understand callback registration for Dataverse triggers
• Understand flow failure notifications in Power Automate
• Update or roll back Power Automate for desktop
• Version control in Power Automate for desktop

Power Pages

Updated

• Access user and website details with server objects
• Configure managed rules in Power Pages WAF
• Create a site with Power Pages
• Create and manage server logic in Power Pages
• FAQs about using SAML 2.0 in Power Pages
• Get started with the Power Pages plugin for GitHub Copilot CLI and Claude Code
• Identity provisioning in Power Pages
• Known issues for Power Pages
• Power Pages server logic overview
• Roles required for Power Pages administration
• Set up site authentication

Power Platform administration

New

• Power Platform and Dynamics 365 macro regions
• Power Platform inventory sample queries

Updated

• About the Microsoft Dataverse for Teams environment
• Account assistant for SAP solutions
• Allow external language models for generative responses
• App object in Power Apps
• Apply seed data
• AsType and IsType functions
• Automate deployments with Dataverse Git integration and pipelines in Power Platform
• Automate service order lifecycle and SLA governance with Power Platform
• Automatic deletion of Power Platform environments
• Back up and restore environments
• Business continuity and disaster recovery
• Choose the region when setting up an environment
• Collect audit logs using a custom connector (Deprecated)
• Collect audit logs using Microsoft Graph API
• Collect audit logs using Office 365 Management API
• Collect historic audit log events
• Compliance and data privacy
• Configure authentication for SAP Procurement solutions
• Configure Dataverse search for your environment
• Configure environment variables for SAP and Power Platform SAP solutions
• Configure security groups
• Connect Microsoft Power Platform and SAP
• Create and manage environments in the Power Platform admin center | Microsoft Docs
• Create Entra agent users (preview)
• Customize the SAP Procurement solutions
• Data Export inventory setup
• Dataverse capacity-based storage details
• Dataverse capacity-based storage overview
• Dataverse for Teams environment management
• Develop a tenant environment strategy to adopt Power Platform at scale
• Dynamic values
• Ensure data retention and mobility
• Environment and data policy management
• Establish tenant hygiene with the CoE Starter Kit
• Explore Power Platform and SAP integration
• Extend and customize CoE Starter Kit components
• Extend canvas apps in your Microsoft Power Platform solutions
• Extend cloud flows
• FAQs about source code integration
• Frequently asked questions about the Data Export integration
• Get started with the SAP Procurement template
• Get support in the Power Platform admin center
• Global Secure Access for Copilot Studio agents
• Important changes (deprecations) coming in Power Platform
• Install and set up Account assistant for SAP solutions
• Install and set up Integration assistant for SAP solutions
• Install and set up the SAP Setup Assistant template for Power Platform
• Install and set up the SAP Supplier Self Service template for Power Platform
• Install the SAP Procurement template
• Integration assistant for SAP solutions
• IP firewall in Power Platform environments
• Licensing
• Manage feature settings
• Manage the SAP Supplier Self Service template for Power Platform
• Manage your customer-managed encryption key
• Managed availability
• Managed operations
• Microsoft Dataverse reference architectures and solution ideas
• Microsoft Power Platform Center of Excellence (CoE) Starter Kit transition to Power Platform admin center
• Miscellaneous privileges
• Monitor for general error handling
• Move data across regions for Copilots, AI agents, and generative AI features
• Overview of Power Platform and Copilot Studio reference architectures
• ParseJSON function
• Patch function
• Plan mission critical workloads
• Power Apps reference architectures and solution ideas
• Power Apps US Government | Microsoft Docs
• Power Automate reference architectures and solution ideas
• Power Platform and Dynamics 365 datacenter regions
• Power Platform and SAP for SAP consultants
• Power Platform Center of Excellence (CoE) Starter Kit overview
• Power Platform environments overview
• Power Platform inventory
• Power Platform inventory schema reference
• Preview and experimental AI models
• Programmability and Extensibility – Power Platform API – 2020-10-01 – List tenant settings (preview)
• Programmability and Extensibility – Versioning and support
• RecordOf and Type functions
• Requirements to integrate SAP with Power Platform
• Safeguarding Dataverse sessions with IP cookie binding
• SAP Procurement template for Power Platform
• SAP Setup Assistant template for Power Platform
• Securely access customer data using Customer Lockbox in Power Platform and Dynamics 365
• Set up app quarantine components | MicrosoftDocs
• Set up clean-up for orphaned objects
• Set up connections for SAP solutions
• Set up Dataverse for Teams environment management | MicrosoftDocs
• Set up Developer Compliance components
• Set up environment request components
• Set up environments and data policies
• Set up inactivity notifications components | MicrosoftDocs
• Set up Innovation Backlog components
• Set up inventory components
• Set up Microsoft Entra ID for SSO to SAP in OData connector
• Set up Microsoft Entra ID using SAP SuccessFactors
• Set up nurture component
• Set up on-premises data gateway for SAP
• Set up other core components
• Set up the CoE Starter Kit: Prerequisites and instructions
• Set up the Power BI dashboard
• Set up virtual network support for Power Platform
• Special system users and application users
• Track, manage, and scale Copilot adoption in the Power Platform
• Update the Center of Excellence (CoE) Starter Kit
• Use core components
• Use governance components
• Use Integration assistant for SAP solutions
• Use table segmentation in solutions in Power Apps
• Use templates and prebuilt agents
• Use the Power Platform administration planning component
• Use the SAP Goods Receipt Management app
• Use the SAP Purchase Order Management app
• Use the SAP Requisition Management app
• Use the SAP Solution Administrator model-driven app
• Use the SAP Vendor Invoice Management app
• Use the SAP Vendor Management app
• Use the SAP Vendor Payment management app
• View licensing and capacity recommendations
• Virtual Network support overview
• What is the SAP Supplier Self Service template for Power Platform?
• What’s new in Microsoft Power Platform guidance
• What’s new in the Power Platform and Copilot Studio Architecture Center
• Work with solutions using the Dataverse SDK with Power Platform

Power Platform developer

New

• Asynchronous client operations
• Relationship management
• Use metadata to customize tables and columns

Updated

• Authentication Overview for Power Platform Playwright Samples
• Dataverse SDK for Python overview
• Delete Data in Bulk to Reduce Storage Use
• Getting started
• Modern theming API component | Microsoft Docs
• Power Apps code apps overview
• Query data
• Quick guide to Dataverse
• Style components with modern theming
• Use SQL to Query Data With the Dataverse Web API
• Work with data using code in Microsoft Dataverse
• Work with Dataverse Data Using Python SDK
• Microsoft Dataverse SDK for Python package reference
• Microsoft Dataverse SDK for Python Changelog
• Asynchronous service
• Microsoft Power Platform API reference
• Work with solutions using the Dataverse SDK with Power Platform

Power Platform Connectors

Updated

• Custom connectors overview

AI Builder

Updated

• End of AI Builder credits
• Licensing and Copilot Credits

The post What’s new in Power Platform: June 2026 feature update 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.

• Fresh, grounded data. Fabric gives your Copilot and AI agents direct access to live Dataverse records — no stale exports, no sync delays.
• Insight to action. Fabric analyzes the data; Dataverse acts on it — powering agents that don’t just answer questions, they complete workflows.
• Unified governance. The same data powering your reports powers your AI with consistent security and compliance across Power Platform and Fabric.

Whether you run customer engagement or finance and operations workloads, low-latency sync delivers a single, unified sync experience with dramatically improved throughput and reduced data freshness latency. 

The challenge: data freshness matters 

Organizations running Dynamics 365 and Power Platform rely on timely, accurate data to drive analytics, reporting, and downstream processes. Until now, syncing data from Dataverse to your analytics layer involved variable latency depending on the link type, workload size, and table configuration. For teams building dashboards, running operational reports, or feeding AI models, every hour of delay translates to decisions made on stale data. 

We heard this feedback clearly: you need your Dataverse data in Fabric faster, with less complexity, and with a consistent experience regardless of whether you’re running Dynamics 365 customer engagement apps, finance and operations apps, or custom Dataverse apps. 

What is Low-latency sync? 

Low-latency sync is the next generation of the Dataverse sync engine. It replaces the existing sync pipeline with a redesigned data path that reduces end-to-end latency for both initial sync and ongoing incremental (delta) sync operations. 

Key improvements: 

• Faster initial sync: Full table replication completes significantly faster, getting your historical data into Fabric sooner. 

• Blazing fast delta sync: Incremental changes flow from Dataverse to Fabric with significant improvements over traditional Fabric Link. Actual sync times depend on initial load, data churn, table sizes, and number of columns, but the performance gains are substantial across the board. 

• Higher throughput for finance and operations apps: Throughput increases to upwards of 1M+ records per hour per table*, up from the previous 100K to 700K range. 

*Performance observed in lab environments and simulated conditions. Actual throughput may vary depending on table size, region, data churn, and customer environment characteristics. 

Under the hood: fewer hops, better reliability 

Fabric Link vs Low-latency sync architecture. The diagram above illustrates the architectural change at the core of low-latency sync. 

Fabric Link (today) follows a three-step path: data is read from the Dataverse database, serialized to an intermediate CSV format, and then converted to Delta Parquet before being made available in your Fabric Lakehouse via a shortcut. 

Low-latency sync eliminates the intermediate CSV step entirely (see diagram above). Data flows directly from the Dataverse database to Delta Parquet, removing one full hop from the pipeline. 

This is not just a latency improvement. Removing the CSV serialization and deserialization step has a direct impact on reliability: 

• Fewer failure points. Each hop in a data pipeline is a potential point of failure. The CSV stage involves serialization, temporary storage writes, and reads before the Delta conversion can begin. Eliminating this step removes an entire class of transient errors (I/O failures, serialization bugs, storage throttling on intermediate files). 

• Reduced resource contention. The CSV stage consumes compute and storage resources that are no longer needed. This frees capacity for the operations that matter: reading from the source database and writing the final Delta Parquet output. 

• Simpler retry and recovery. With fewer stages, the sync engine has a shorter, more predictable pipeline to manage. When issues do occur, recovery is faster because there is less intermediate state to reconcile. 

• Consistent data format. Going directly to Delta Parquet means data is written once in its final format. This eliminates edge cases where CSV encoding differences or schema mismatches between the CSV and Delta stages could cause data quality issues. 

The result: faster sync times and a more reliable pipeline, with fewer operations that can go wrong between your Dataverse database and your Fabric Lakehouse.

What this means for your team 

• For data analytics and reporting teams. Your Fabric Lakehouse, dashboards, and Power BI reports get refreshed data faster. Reduced sync latency means the gap between a transaction in Dynamics 365 and its availability in your analytics layer shrinks significantly. This directly improves the accuracy and timeliness of operational and executive reporting. 
• For system administrators. Low-latency sync is designed as a drop-in improvement. We are releasing it in a controlled manner across stations, starting with early release stations and then expanding one station at a time on a weekly cadence. There is no separate opt-in experience. Once your station is enabled, new Fabric Link configurations can use the new sync engine through the same familiar setup experience in the Power Platform admin center. 
• For leadership and business stakeholders. Faster data replication means faster insights. Whether your organization tracks revenue, inventory, case resolution times, or customer engagement metrics, low-latency sync closes the gap between operational systems and the analytics that drive decisions. 

Performance at a glance 

• Customer engagement apps: Significant improvement in delta sync latency over traditional Fabric Link. 

• Finance and operations apps: Throughput upwards of 1M+ records per hour per table*. 

*Performance observed in lab environments and simulated conditions. Actual throughput may vary depending on table size, region, data churn, and customer environment characteristics. 

Tentative timelines 

These rollout windows are approximate and may change as we monitor health and progress through each deployment wave. 

Prerequisites for Finance and Operations

If you are running Finance and Operations (FnO) apps, verify prerequisites and minimum supported build requirements in the public documentation before enabling low-latency sync.

See: Low latency sync Link to Fabric Documentation

How to get started 

New Fabric Link customers 

1. Navigate to the Power Platform admin center. 

2. Set up a new Fabric Link for your Dataverse environment. 

3. If your station is part of the current rollout wave, low-latency sync is made available as part of the standard setup experience. There is no separate enrollment step or preview sign-up. 

4. If your station has not yet been enabled, no action is required beyond watching for rollout availability. Once enabled, you can complete setup and start syncing through the new engine. 

Existing Fabric Link customers (early access) 

If you want to start using low-latency sync, watch for availability in your station as the controlled rollout progresses: 

1. Unlink your existing Fabric Link profile. 

2. Relink and follow the same setup flow once your station is enabled for low-latency sync. 

3. Your profile will run on the new sync engine without a separate preview opt-in step once the rollout reaches your station. 

Note: Unlinking and relinking will trigger a full initial sync for all configured tables. 

How to confirm low-latency sync is enabled 

To confirm that your environment is running in low-latency mode, open the experience and select Azure Synapse Link from the navigation. On the link list page, if you see the Low-latency mode flag on your Fabric link, low-latency sync is enabled for that profile. 

Low-latency mode flag in Azure Synapse Link. Azure Synapse Link experience showing the Low-latency mode flag on the Fabric link profile. 

What about Synapse Link and Export to Data Lake? 

Low-latency sync applies to Fabric Link configurations. If you are currently using Synapse Link (BYOL/BYOS) or Export to Data Lake (COMO), here is what to expect: 

• Synapse Link (BYOL/BYOS): Continues to function as-is. We encourage customers to evaluate Fabric Link with low-latency sync for improved performance and a streamlined experience. 

• Export to Data Lake: Export to Data Lake has been deprecated and the service is being retired. We strongly recommend evaluating and moving over to Fabric Link with low-latency sync post GA. There is no further extension or exception process planned for the Export to Data Lake deprecation. 

Looking ahead 

Low-latency sync is a foundational step toward making Dataverse the most connected operational data platform. With all sync workloads consolidated on a single engine, we can deliver improvements faster, reduce operational complexity, and unlock new scenarios for real-time analytics and AI. 

We are actively working on expanded throughput optimizations to enable continued performance improvements for large-scale environments. 

We want your feedback 

Your feedback directly shapes the GA release and future roadmap. 

• Try it: If your environment is in an enabled station, set up or relink Fabric Link through the Power Platform admin center and evaluate low-latency sync. 

• Share feedback: Reach out to your Microsoft account team or join Viva Engage community to share your feedback.

• Learn more: https://aka.ms/lowlatencylearnmore 

The post Announcing Low-latency sync for Dataverse to Fabric in GA appeared first on Microsoft Power Platform Blog.

This matters because MCP already gives makers and developers a consistent way to connect agents to real business data without every client needing a custom Dataverse integration. Our enhancements ensure the Dataverse MCP experience is easier to reason about through a clearer tool shape. Agent surfaces like Copilot Studio, GitHub Copilot in VS Code, GitHub Copilot CLI, Claude Desktop, Claude Code, and other MCP-compatible clients can now connect to the Dataverse MCP endpoint and experience this new tool shape.

What changed

The important change is not that Dataverse supports MCP. It already does. The change is that the experience is now easier to understand through a concrete set of tools. Instead of thinking about MCP as a generic connection, we can now talk about the actual tools an agent can use. The Dataverse MCP server exposes tools for common data and metadata tasks, including:

This tool shape is important because it defines the contract between the agent and Dataverse. The agent is not just connected to Dataverse in a broad sense. It has a set of named capabilities that can be reasoned about, allowed, blocked, audited, and improved over time.

For additional information, please see the documentation for full list of Dataverse MCP tools and billing rates.

Why the tool shape matters

For users, makers, and pro developers, the MCP tool shape creates a cleaner mental model.

If an agent needs to:

• Understand the data model, it can use tools such as search, describe, and schema-related responses.
• Answer a question from data, it can use read_query or search_data depending on whether the scenario is structured query or broader search.
• Create or update business data, it can use create_record, update_record, or delete_record with the right approvals and safeguards.
• Help scaffold or evolve a simple schema, it can use table tools such as create_table, update_table, and delete_table.
• Move files in or out of Dataverse, it can use init_file_upload, commit_file_upload, and file_download.

That means agent experiences can move from “tell me how to do this” to “help me inspect, reason, and act against my environment,” while still going through explicit tool boundaries.

A practical example

Imagine a user asks: Which accounts have open follow-up items, and can you create a task for the ones missing an owner?

With the MCP server connected, the agent can use the Dataverse tools to inspect the relevant tables, query the data, and create records where appropriate. The interaction becomes more grounded because the agent can work with the actual Dataverse environment instead of relying only on user-provided context.

Governance still matters

The MCP server does not remove the need for governance. In fact, the tool shape makes governance more visible.

Administrators have control over which clients have access to to the environment via MCP server. This ensures that only approved agent surfaces are accessing business data. Additional capabilities such as ‘allowed tools’ and strong role based access control ensure users only have access to data that their security context allows.

The practical guidance is:

1. Enable MCP only for environments where agent access makes sense.
2. Allow only approved clients.
3. Understand which tools are exposed.
4. Treat write-capable tools differently from read-only tools.
5. Validate that users only access data they are already permitted to see.

Summary

The most interesting part of this Dataverse MCP server enhancement is the move toward a clearer, more concrete tool shape.

The updated tool shape makes Dataverse more agent-ready. It gives agents a standard way to discover tables, inspect schema, query data, and use controlled Dataverse tools. For makers, this means more natural AI-assisted workflows. For developers, it means a cleaner integration pattern. For admins, it creates a more explicit surface to govern.

MCP turns Dataverse into something agents can use directly, but the tool shape determines how safe, useful, and predictable that experience becomes.

Additional resources

• Connect to Dataverse with Model Context Protocol
• Configure the Dataverse MCP server for an environment

The post Dataverse MCP Server: Understanding the New Tool Shape appeared first on Microsoft Power Platform Blog.

Companion post to our Build 2026 session: Microsoft Dataverse plugin: unleashing coding agents on the enterprise

Coding agents are powerful, but without domain tooling they hallucinate and produce broken solutions. The Dataverse plugin for coding agentssolves this by giving AI agents guardrailed access to tables, columns, relationships, views, security, and solutions.

In our Build 2026 session, we showed how a natural-language request triggers multi-step provisioning, data imports, and validation. This is all executed autonomously, through the plugin’s tool integration and patterns that make agent-driven Dataverse development reliable at scale.

To bring this to life, we built a series around Zava Coffee Co., a growing B2B roaster and distributor running on spreadsheets, email, and copy-paste. When it came time to modernize, they didn’t need a massive team and spend weeks in the the various portals. Instead, they installed the Dataverse plugin and described what they needed, in plain English, from a GitHub Copilot terminal.

This post, and accompanying video, walks through the three scenarios:

1. Maya, a developer building her first data model, app form and view
2. Riya, a Revenue Ops analyst running her CRM in natural language
3. Amara, a platform admin locking down security across two regions.

Scenario 1: Zero to App in One Session

Persona: Maya, Developer, new to Dataverse
Goal: Turn four operational spreadsheets into a working Dataverse application with schemas, relationships, and real data.

Maya had never touched Dataverse. She didn’t know her org URL, didn’t know what a publisher prefix was, and shouldn’t have to. She installed the plugin, typed one sentence “Connect me to my Dataverse environment” and the agent discovered her environments from her Microsoft identity, configured everything, and verified the connection.

Then she describes her roast batch tracking system in business terms: beans, batches, quality checks, orders, and the relationships between them. One prompt produced four tables with choice columns, lookups, a self-referential parent-batch relationship for re-roasts, a many-to-many between batches and orders, a main form, and a filtered view — all packaged in a solution.

The data import is where it gets real. Maya pointed the agent at the team’s four Excel files. No GUIDs anywhere, just business keys for a bean variety and batch numbers. The agent figured out dependency order, loaded parent tables first, resolved the self-referential re-roast links, split a comma-separated batch list into proper many-to-many associations, and left an unlinked order alone instead of erroring out. That’s a data pipeline, not a sample generator.

What the plugin solved: Maya went from zero Dataverse knowledge to a connected, working application that included schemas, relationships, forms, views, and three years of real operational history, all without opening the maker portal, reading a setup guide, or writing a single line of FetchXML.

Scenario 2: Talk to Your CRM in Plain English

Persona: Riya, RevOps Analyst
Goal: Run Friday pipeline prep in five minutes instead of forty-five minutes, no Advanced Find, no Excel pivots, no chasing teammates in Teams.

Riya already lives in a terminal. Every Thursday she preps Carlos’s sales pipeline review by pulling open deals, flag at-risk cafés, makes sure last week’s calls are logged. Today that’s forty-five minutes of Advanced Find queries, Excel exports, and detective work.

With the Dataverse plugin, she asked: “Show me Carlos’s open opportunities over $100K closing this quarter.” The agent looked up Carlos by name in the systemuser table, translated “this quarter” into a date range, and returned café names, deal names, dollars, and stages — no GUIDs, no statecode = 0, no estimatedclosedate syntax.

Then she asked for “cafés in Portland that haven’t reordered in 30 days.” That’s not a field, it’s a relationship plus date math. The agent joined accounts to closed-won opportunities, computed the gap, and handed Riya a clean call list.

The trust moment: When Riya said “Add a note to the Portland cafe opportunity,” the agent found the open deal on that account. She also logged a phone call on behalf of Carlos, the agent set the owner to Carlos (his call), marked it completed (already happened), resolved the contact as a participant, and linked it to the right account, all inferred from one sentence.

What the plugin solved: Riya collapsed 45 minutes of Advanced Find, Excel pivots, and manual activity logging into five minutes of conversational CRM access. Carlos got a cleaner pipeline review without doing anything differently.

Scenario 3: Manage Your Environment Like a Pro

Persona: Amara, Platform Admin
Goal: Draw security boundaries for two regions and three job functions, validate every line, and package it in a deployable solution.

Zava doubled in size and opened a Seattle hub. Amara’s problem: warehouse staff can see deal sizes, sales reps can see quality scores, and anyone can read customer lifetime value. She needed to draw lines and she wanted to describe the security model once, not click through six sections of the admin portal.

She connected with an admin posture: “Verify I have System Administrator privileges before we start.” The agent confirmed her role before offering to do anything destructive. Then she described the full security plan in one prompt: two business units (Portland, Seattle), three custom roles scoped appropriately, field-level security on the sensitive lifetime_value column, an access team template for cross-region collaboration, and three user assignments, all in a ZavaSecurity solution.

The invisible prerequisites: The agent enabled the column for field-level security at the schema level before creating the Field Level Security (FLS) profile. This step, when missed, produces no error and no audit entries. It assigned the profile to roles, because a created-but-unassigned profile does nothing. It added every security component to the solution explicitly, since roles and FLS profiles don’t auto-add.

Validation by impersonation: Amara asked the agent to simulate each user’s access. The result was a clear pass/fail table — Diego can read accounts but not lifetime_value (FLS), Marcus can read roast batches but not accounts (role), nobody can see across business units. Red Xs and Green checkmarks in all the right places, with the why annotated next to each cell. That’s the admin equivalent of a unit test. Allconfiguration confirmed in seconds, not browser-tab-per-user.

She then shared one record cross-region via the access team template. This was one sentence, no GUIDs and enabled three-layer column auditing (org, table, column) so future reads are logged.

What the plugin solved: In one session, Amara stood up two BUs, three roles, FLS with proper assignments, a team template, three user assignments, validated by impersonation, configured a cross-region share, and turned on auditing. Every component lives in a solution she can version and redeploy across environments.

Three Users, Three Jobs, One Unified Approach

The common thread across all three scenarios is : describe your intent in plain language, the agent translates it into the right combination of Dataverse operations. Maya never learned what a publisher prefix is. Riya never wrote FetchXML. Amara never opened the BU management UI. Each person brought a different problem and a different level of platform expertise and the same plugin met all three where they were.

The Dataverse Skills pluginis available now on the Claude and GitHub Copilot marketplaces. Install it, connect, and start building.

👉 Watch the full Build 2026 session:  Microsoft Dataverse plugin: unleashing coding agents on the enterprise 

Learn more about what’s new in Dataverse: aka.ms/DataverseMay2026

The post Microsoft Dataverse Plugin: Unleashing Coding Agents on the Enterprise – Microsoft Build 2026 appeared first on Microsoft Power Platform Blog.

Copilot, agents, and AI-first projects have multiplied both the people who build and the places they build in. A tenant that had a few dozen environments two years ago can have thousands today. And what you need to govern is no longer just which connectors — it’s which actions and MCP servers inside them that AI tools utilize. Today, we’re making advanced connector policies (ACP) generally available to meet that moment.

Governance built for how people actually work today

The old model asked a lot from administrators. Every connector had to be sorted into a bucket, and a single environment could be touched by several overlapping DLP policies at once — a tenant-wide rule here, an exception there, even an environment-specific DLP policy a maker created themselves. Predicting what one small change would do often meant holding several rule scopes in your head and hoping to avoid a “scream test”, the DLP wizard was optimized for placing policies yet made it hard to identify the effective policy on a given asset. ACP replaces that guesswork with one simple idea: every environment has at most one policy in effect — inherited from an environment group or set directly on the environment. That’s the whole mental model.

What changes with ACP

ACP is a ground-up redesign of how you manage what your apps, flows, and agents can use from a connector perspective. The headlines:

• Govern what used to be non-blockable. On managed environments and environment groups, you can block all connectors and actions. In classic DLP policies some connectors cannot be touched.

• Goodbye business and non-business. The old classifications are gone. There’s one clear question: is this connector or action allowed vs blocked.

• Govern your AI tools. Agents reach out to the world through MCP servers; ACP lets you block an MCP server just like any other connector or action.

• An allowlist, not a sorting exercise. You start from “nothing extra is allowed” and add the connectors your teams need. When a brand-new connector appears on the platform, it’s blocked until you decide — so nothing slips in just because it’s new.

• Down to the individual action. Allow a connector but switch off a risky action or an old, deprecated one. For the first time you can see which actions are deprecated, which are internal, and which are triggers — right where you set the policy.

Where ACP shines: scalability

Massive volume of environments and assets that customers manage today in the age of AI are the reasons why ACP was built. With personal developer environments (PDE) and environment routing, a new maker creating their first app, agent, or flow can automatically get a dedicated environment created just for them. That’s great for maker productivity, but it made classic DLP’s include and exclude mechanics nearly impossible to keep current. Every new environment introduced another policy-scoping decision, another exception to track, and another chance for governance to drift.  

ACP changes that model completely: because it is a native part of environment groups, the right connector policy follows the environment automatically. As soon as a new environment is created and routed to a group, the correct policy snaps into place — with zero friction for makers and no ongoing environment-by-environment overhead for IT.

The shift to earlier feedback

ACP has enforced policy at runtime throughout public preview this past year. That means when an app, flow, or agent invokes a connector, the platform performs a last-mile check against the effective policy and blocks the action if it is not allowed. Runtime enforcement is essential because it protects the business at the exact moment data could move — but it also comes at the very end of the maker journey. A maker could build a new asset, wire up connectors and actions, and only discover at runtime that the experience could never successfully run because it violated policy.

With this GA release, we are shifting that feedback much earlier. Now, when a maker first adds a connector or action to an app, flow, or agent, ACP can tell them immediately whether that choice is allowed in the environment they are building in. Instead of waiting until the asset is complete — or worse, until it runs — makers get clear guidance while they are still designing. And soon, we will go one step further: blocked connectors and MCP servers will be greyed out up front, so makers can focus only on the tools that are available, compliant, and expected to succeed.

What comes next

As we look ahead, we know there are still important capabilities in classic DLP that customers rely on today — especially custom connectors and endpoint filtering. Until those experiences fully land in ACP, customers can use ACP and DLP together in mixed mode, combining the strengths of both systems where they need to. That means using ACP for its simpler model, action-level control, and MCP governance, while DLP continues to cover the remaining scenarios that have not yet reached parity. We are also building a new feature called “ACP only mode” which is in public preview now and will be GA soon, allowing you to easily ignore DLP for an environment or group of environments where needed and reducing the need to continue to include or exclude environments from your DLP policies. This is the easiest way to onboard to ACP for customers who don’t need those extra capabilities as you can leverage environment groups, routing, ACP and ACP only mode to completely migrate away from DLP.

Getting started

You can apply ACP two ways: define it once on an environment group to govern a whole fleet or set it directly on a single environment for the high-risk, pilot, or regulated ones that need their own rules. You’ll find it in the Power Platform admin center under security > data and privacy for a single environment, or on the rules tab of an environment group to manage at scale. DLP isn’t going anywhere overnight — you can run both side by side while you migrate, and switch to a single, clean ACP-only posture when you’re ready.

Before making connector policy changes, we also encourage customers to review Power Platform inventory, which now includes preview visibility into connector and operation usage across apps, flows, and agents. That foundation creates a path to impact analysis for ACP changes, helping admins understand ahead of time which resources, connectors, and actions could be affected before they publish a policy update.

Governance shouldn’t slow your teams down; it should give them a safe lane to move fast in. That’s what advanced connector policies are built for. Explore the documentation at aka.ms/LearnACP, try it in a single environment or group, and tell us what you think.

The post Advanced connector policies are generally available appeared first on Microsoft Power Platform Blog.

• Customer Self‑Service Portal
• Partner Portal
• Employee Self‑Service Portal
• Community Portal

When you provision a new site using any of these templates, it’s automatically built on the Enhanced Data Model with Bootstrap 5. No additional configuration is needed.

What’s new

• Enhanced Data Model (EDM) for key D365 templates is now generally available. New sites created with any of the four supported templates are automatically provisioned on the EDM, giving you the same modern architecture that Power Pages starter templates already use.
• Bootstrap 5 out of the box – All four templates have been migrated from Bootstrap 3 to Bootstrap 5, delivering improved responsiveness, accessibility, and alignment with current Power Pages UI standards.
• Full Design Studio and Management App support – The Power Pages Design Studio and Power Pages Management app fully support the new EDM‑based templates, including all updated attributes, relationships, forms, and views. Your authoring and customization experience remains seamless.

Why this matters

• Faster provisioning – Sites on EDM provision significantly faster, reducing the time from template selection to a live development environment.
• Streamlined ALM – Website configurations are solution-aware and stored in Dataverse solutions, with support for Environment Variables and Power Pipelines for deployments – making it easier to transport customizations across environments using standard application lifecycle management processes.
• Faster platform updates – Enhancements and bug fixes are delivered more efficiently on the Enhanced Data Model. Customers are not required to actively manage Power Pages solutions to stay up to date, feature updates and security patches are automatically shipped to ensure ongoing security and compliance.
• Modern, accessible UI – Bootstrap 5 brings a responsive grid system, improved accessibility defaults, and a cleaner component library, helping you deliver a polished experience to customers, employees, and partners without additional front‑end work.

With these four templates now on EDM, Dynamics 365 portals benefit from the same platform‑level investments and future enhancements as all other Power Pages sites.

Important: This update applies to newly provisioned sites only. Existing sites on the standard data model continue to operate without impact. Migration tooling for these four Dynamics 365 templates is not yet available but is coming soon.

How to get started

Prerequisites

• Sign in to the Power Platform admin center.
• Go to Manage > Environments > Select your Environment > Resources > Power Pages sites and ensure the Switch to enhanced data model toggle is turned on for your environment.
• Verify your environment has Power Pages Core Package v1.1.2602.230 or later. For upgrade steps, see Update the Power Pages solution.

Create a new site

1. Open the Power Pages home page.
2. Select Create a site.
3. Choose one of the four supported Dynamics 365 templates and select ‘Choose this template’.
4. Fill in the required details and select ‘Done’.
5. Your new site is provisioned on EDM with Bootstrap 5 automatically.

Learn more

• Enhanced Data Model overview – https://learn.microsoft.com/en-us/power-pages/admin/enhanced-data-model
• Power Pages Management app – https://learn.microsoft.com/en-us/power-pages/configure/portal-management-app

We’d love to hear your feedback! Share your thoughts on the Power Pages community forum.

The post Enhanced Data Model and Bootstrap 5 Now Available for Dynamics 365 Portal Templates appeared first on Microsoft Power Platform Blog.

With GA, the plugin now covers the part of the journey that decides how your website project reaches your users, i.e., getting to production safely. You get Application Lifecycle Management (ALM) with the native Power Platform Pipelines, security hardening for your live site, and an expanded selection for authentication setup, all through the same conversational workflow you already know.

What’s new at GA

The preview helped you build. GA helps you ship, govern, and protect what you build.

• ALM and pipelines. Promote your site from development to test to production with native Power Platform Pipelines, no external infrastructure required.
• Site security. Configure a web application firewall, tighten browser security headers, scan your live site for vulnerabilities, and audit table permissions before you go live.
• Authentication and access. The /setup-auth skill now configures more than one identity provider, generates registration and profile pages.

Everything from the preview is still included, generally available and production supported: site creation, deployment, activation, data modeling, Web API integration, server logic, cloud flows, and SEO.

Move to production with ALM and pipelines

A site that lives only in a development environment isn’t finished. The new ALM skills package your site into a Dataverse solution and deploy it across environments using pipelines in Power Platform, Microsoft’s native, in-product Continuous Integration and Continuous Delivery (CI/CD). There is no separate build server to stand up and no specialized ALM knowledge required to get started.

Describe what you want, and the plugin runs the right skills. Start with /plan-alm if you’re not sure where to begin: it’s the orchestrator and runs the other skills for you. If you already know what you need, run a direct skill on its own.

Whichever path you take, the deployment plan is reviewable before anything runs, so you decide the promotion path and approvals up front. The plugin then handles the export, import, version handling, and environment wiring that used to be manual, repetitive work.

Secure your site for production

Going to production for an external website means exposing your site to the open internet. The new security skills help you close common gaps without leaving your agent session, and each one explains what it found in plain language. Start with /security-review if you’re not sure where to begin, it’s the skill orchestrator which steps you through the others. If you want to target one area, run a direct skill on its own.

Whichever path you take, the plugin recommends a safe configuration, shows you the implications, and waits for your approval before making any change.

Set up authentication and access

Authentication is one of the first things a real site needs, and small misconfigurations are common. The improved /setup-auth skill generates a clean sign-in and sign-out flow with anti-forgery token handling, and it now goes further:

• More than one identity provider. Beyond the default Microsoft Entra ID provider, configure additional identity providers, such as other OpenID Connect or OAuth 2.0 providers, so you can offer the sign-in options your users expect.
• Registration and profile pages. Give users a way to sign up and manage their own account details, not just sign in and out.

Paired with /create-webroles, you can stand up authenticated access, self-service registration, and role-aware UI in a single conversation.

You stay in control

As in preview, the plugin proposes and you approve. The Data Model Architect, Web API Permissions Architect, and Server Logic Architect agents present their plans before making changes, and the new ALM and security skills follow the same pattern. Nothing is created, deployed, or hardened until you confirm.

Get started

Install or update the plugin and PAC CLI

If you’re new to the plugin, install it from the Microsoft marketplace and restart your agent. For the easiest setup, use Quick Install (recommended),

Already building with the preview? Turn on auto-update from the /plugin menu, or reinstall to pick up the GA skills. Then try the new flow end to end: run /create-site to build, /security-review to harden, and /plan-alm to promote your site to production.

Get started with the Power Pages plugin for GitHub Copilot CLI and Claude Code.

We are looking for your feedback

Your feedback helps us improve the developer experience on Power Pages. Share your thoughts and reach out on the Power Pages Community Forum. You can also submit ideas through the Power Pages Ideas portal.

Resources

• Get started with the Power Pages plugin for GitHub Copilot CLI and Claude Code
• Pipelines in Power Platform
• Use Power Platform pipelines with Power Pages
• Web Application Firewall for Power Pages
• Manage your site’s Content Security Policy
• GitHub Copilot CLI and Claude Code

The post Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available appeared first on Microsoft Power Platform Blog.