We’re making this change because of how our customers actually work. Few organizations run a single Microsoft product in isolation. Dynamics 365, Power Platform, Microsoft 365, Microsoft 365 Copilot, and custom agents built in Microsoft Copilot Studio increasingly operate together to power business processes, employee productivity, and AI transformation. Bringing this content together means you can see what is coming across all of these products in one view, filter it to your own environment, and plan across products.

Moving from release waves to always-on disclosure
Alongside this move, we’re also changing when roadmap information appears. We’re retiring the twice-yearly release wave 1 and release wave 2 model in favor of continuous publishing. We’ll publish new capabilities as soon as plans are committed and ready to share, rather than holding them until the next scheduled wave.

Once published, each roadmap item remains current as it progresses through In Development, Rolling Out, and Launched, with status and rollout information updated as plans evolve. In practice this means most capabilities will appear on the roadmap sooner than they would have under the wave calendar, and you follow them all the way through delivery rather than losing sight of them after publication.

Working with AI at Work roadmap data
We have designed the AI at Work roadmap to support planning, not just browsing. You can:

Filter roadmap views to the products that matter most to your organization.
Export complete or filtered roadmap views to a CSV file.
Subscribe to updates through RSS.
Share roadmap links directly with stakeholders.
Search and organize roadmap content using feature IDs and advanced filters.
Download the AI at Work roadmap guide to learn how to read and use the roadmap.

For teams that would rather query the roadmap than browse it, the Release Communications MCP Server pulls roadmap information directly into your own AI tools and workflows. Organizations can use it to generate customized roadmap views and planning materials, or to integrate roadmap data into existing tooling and business processes.

What’s not changing
This transition changes how Microsoft communicates upcoming innovation. It doesn’t change how our products are built, released, or deployed.

Products with established release schedules will continue to follow those schedules.
Message Center remains the source for tenant-relevant change notifications.
Microsoft Learn remains the home for product documentation and implementation guidance.

Transition milestones at a glance
When What happens
September 2026 New Dynamics 365, Power Platform, and Dataverse capabilities begin publishing to the AI at Work roadmap.
September 2026 to November 2026 Existing roadmap content with public preview or general availability (GA) date of June 1, 2026 or later will transition to the AI at Work roadmap experience. Ongoing updates and transition notifications will be communicated through Message Center.
By November 15, 2026 The transition completes and Release Planner retires. The AI at Work roadmap becomes the primary destination for public roadmap information.

How to prepare for the transition
The transition will take place over the coming months, and there are a few simple steps you can take now.

Explore the AI at Work roadmap. Spend a few minutes reviewing the AI at Work roadmap and setting filters for the products and cloud environments your organization uses.

Subscribe to updates. See the AI at Work roadmap guide to learn how to use RSS to follow filtered roadmap views and continue using Message Center for changes specific to your tenant.

Update planning references. If your teams rely on release plan links, bookmarks, or internal roadmap documentation, begin updating those references to point to the AI at Work roadmap. Transition guidance will be available throughout the migration period.

Set your own review rhythm. Release wave 1 and release wave 2 gave organizations a fixed moment twice a year to gather stakeholders and plan the period ahead. We recommend establishing a recurring review, monthly or quarterly, depending on how quickly your organization adopts new capabilities, built on a saved filter and an RSS subscription.

AI at Work roadmap transition FAQ
Q. Will there be a September 2026 release wave 2 announcement or release wave 2 release plan?
A. No. New capabilities will be disclosed on the AI at Work roadmap as they become committed, rather than grouped into a twice-yearly release wave announcement.

Q. Will all existing Dynamics 365 and Power Platform roadmap content move to the AI at Work roadmap?
A. Roadmap content with a public preview or general availability date of June 1, 2026 or later will transition to the AI at Work roadmap. Earlier content remains available in existing release plans on Microsoft Learn for historical reference.

Q. What happens to release plans on Microsoft Learn?
A. Beginning in September 2026, new release plans will no longer be published to Release Plans on Learn. Existing release plans will remain available for historical reference, and Microsoft Learn will continue to serve as Microsoft’s documentation platform.

Q. Can I still export roadmap information?
A. Yes. See the AI at Work roadmap guide to learn how to export complete or filtered roadmap views to CSV. Organizations can also use the Release Communications MCP Server to integrate roadmap data into your own AI tools and workflows.

Q. Will my saved views in My Release Plans carry over?
A. Personalized saved views will no longer be available after Release Planner retirement. Personalized saved views are not available on the AI at Work roadmap.

Q. How will I see what has changed since I last looked?
A. The roadmap highlights new and updated capabilities, and both RSS and Message Center can notify you as changes occur.

The post One always-on roadmap: Dynamics 365, Power Platform, and Dataverse join the AI at Work roadmap appeared first on Microsoft Power Platform Blog.

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.

We are announcing that Prompt Columns in Microsoft Dataverse is now Generally Available. Prompt Columns enable makers to use natural language to generate AI-powered classifications, summaries, recommendations, and other insights directly from business data. Unlike traditional AI experiences, the generated insights are persisted within Dataverse tables, making them immediately available to applications, workflows, analytics, and agents across the Power Platform.

From Shipment Delays to Actionable Insights

See how Ashley, a supply chain operations manager, uses Prompt Columns to solve her business challenge. 

Here are the key takeaways:

• By leveraging AI’s ability to interpret free-form business data, Ashley uncovers insights that traditional rules and formulas cannot derive. She can then create additional Prompt Columns that build on those results, such as assessing business severity and operational risk based on the root cause, shipment status, and delay duration. 
• Insights are persisted directly within her business data and they become reusable across business processes. Ashley can create supplier performance scorecards, track recurring delay patterns by supplier or region, automatically escalate high-risk shipments through workflows, build dashboards that surface operational risks, and enable Copilot agents to answer questions such as “Which suppliers are causing the most critical delays and why?” 
• Natural language configuration empowers any maker to apply AI directly to business processes, reducing the expertise and development effort traditionally required to unlock value from AI. Ashley doesn’t need to build machine learning models, write code, or integrate external AI services. 

The result is faster identification of operational risks, reduced manual effort, more informed decision-making, and AI-generated intelligence that continuously powers business processes.  

Enterprise Impact Across Core Business Scenarios 

Here are some common Prompt Column scenarios:

• Sales Effectiveness and Revenue Growth: Analyze lead and opportunity data, classify intent and likelihood to convert, summarize customer needs, and recommend next actions, helping sales teams prioritize high-value opportunities, personalize engagement, and improve conversion rates. 
• Risk Management and Compliance: Flag compliance risks, detect escalation signals, and classify interactions by risk level. Regulated industries can potentially transition from manual sampling to AI-assisted monitoring, with the potential to reduce exposure. 
• Supply Chain and Operations Optimization: Analyze supplier records, purchase orders, shipment data, inventory exceptions, and quality inspection notes to classify delays, defects, and recurring vendor issues by severity, enabling faster resolution and more proactive supply chain management. 
• Customer Experience and Retention: Analyze customer feedback to identify satisfaction trends, churn risks, and product improvement opportunities. AI driven classification, sentiment analysis, and personalized recommendations may help organizations proactively intervene, personalize engagement at scale, and strengthen long‑term customer loyalty. 
• Financial Services Fraud Detection and Prevention: Classify risk and identify anomalies, with the expectation of reducing false positives, accelerating investigations, and improving overall regulatory posture. Financial institutions may strengthen fraud prevention by analyzing transactions, communications, and account activities in near real time. 

Prompt Columns: Key Capabilities Drive Enterprise Value 

Strategic Cost Optimization: Configurable filter logic ensures prompts execute only on high‑value records such as priority customers, critical transactions, or specific risk profiles. Organizations reduce AIB or Copilot credit consumption while maximizing business impact. 

Monitor Every Execution: Prompt Column activity is logged in Power Automate’s AI Builder Activity experience, where makers and admins can view execution history, monitor consumption, and review prompt activity. This provides visibility into how Prompt Columns are being used and the credits consumed across your environment. 

Execute AI Only When It Matters: A prompt is executed when one or more of its defined input columns change on the entity to which the Prompt column belongs. If relevant data isn’t updated, Prompt Columns doesn’t execute, eliminating unnecessary cost.

Flexible Execution Control: Enable or disable individual prompts without deleting columns or losing historical data. Pause execution during maintenance, testing, or budget cycles, then reactivate instantly.

Extended Data and Context Awareness: Define prompts on lookup fields and activity types such as emails, for a richer understanding of each record. 

Scale Without Performance Compromise: Prompt execution runs asynchronously, decoupling AI processing from real-time transactions. Systems remain responsive while thousands of records are processed per hour. This gets rid of the traditional trade-off between intelligence and performance. 

Transform Your Enterprise

Start your AI journey with Prompt Columns in Microsoft Dataverse, and turn AI into a permanent business advantage. Learn more:

• See the Public Preview blog for Prompt Columns: http://approjects.co.za/?big=en-us/power-platform/blog/2025/08/04/prompt-columns/
• Prompt columns learn docs: https://learn.microsoft.com/power-apps/maker/data-platform/prompt-column 
• Overview of prompts learn docs: https://learn.microsoft.com/ai-builder/prompts-overview 
• Prompt FAQ: https://learn.microsoft.com/ai-builder/faqs-text-generation 
• Monitor AI Builder models and prompts learn docs: https://learn.microsoft.com/en-us/ai-builder/activity-monitoring

The post Prompt Columns in GA: Turning Business Apps Data into Persisted AI Insights appeared first on Microsoft Power Platform Blog.

We’re excited to announce expansion of the Dataverse plugin across additional coding agent marketplaces, meeting developers where they already work. The plugin is now available for OpenAI and Codex. This adds to the existing support for Claude, Cursor, and GitHub Copilot. Regardless of which coding agent a team standardizes on, they get the same Dataverse expertise: intelligent skill routing, enterprise-grade guardrails, and a consistent natural-language experience across surfaces.

This expansion matters because it reduces adoption friction for customers and partners. Teams can keep their preferred coding agent while using a common Dataverse interaction model for data operations, schema work, solution lifecycle tasks, and environment administration. The result is faster onboarding, more repeatable delivery patterns, and clearer governance alignment without forcing toolchain consolidation.

Installing Dataverse plugin for coding agents in ChatGPT and Codex

The Dataverse plugin for coding agents is available in the marketplace in both the OpenAI and Codex experiences. Choose your preferred surface, go to Plugins, and search for Microsoft Dataverse.

Additional Resources

Cursor Marketplace: https://cursor.com/marketplace/microsoft-dataverse

GitHub Copilot: Dataverse | Awesome GitHub Copilot

Claude Code: https://claude.com/plugins/dataverse

Open-source plugin repo: https://github.com/microsoft/Dataverse-skills

The post Dataverse Plugin for Coding Agents: OpenAI and Codex Marketplace Expansion appeared first on Microsoft Power Platform Blog.

Today, we are excited to share that the Dataverse plugin is now available in the Cursor Marketplace, giving Cursor users a direct path to build with Microsoft Dataverse from inside their preferred AI coding experience.

Bring Dataverse expertise into Cursor

The Dataverse plugin teaches coding agents how to work with the Dataverse MCP server, Python SDK, PAC CLI, and Dataverse CLI. Instead of switching between documentation, admin portals, CLI references, and scripts, developers can describe what they want to accomplish and let the agent route the task to the right tool.

For example, developers can ask Cursor to help show open opportunities over a specific value, create or update Dataverse tables and columns, import a CSV into contacts or accounts, generate sample data for testing, export or import a solution, review security roles and user access, or diagnose schema and data issues in a Dataverse environment.

The plugin includes specialized skills for connection setup, data operations, metadata authoring, queries, solution lifecycle, environment administration, and security. Each skill provides the agent with tested patterns, safe defaults, and tool-selection guidance so developers can stay focused on the business problem rather than the mechanics of each underlying tool.

Built for real enterprise environments

Dataverse is the trusted data platform behind Dynamics 365 and Power Platform. That means any AI-assisted development experience must respect the same security and governance model customers already rely on.

The Dataverse plugin is designed around least-privilege access. It respects existing Dataverse security roles, field-level security, ownership-based sharing, and environment-level controls. It also follows documented authentication patterns and avoids passing prompts, tool arguments, or record data to external services. For MCP access specifically, the plugin works within the existing Dataverse MCP authorization model, including developer authentication, tenant admin consent, and environment allowlisting.

This makes the plugin useful not just for demos or prototypes, but for real enterprise development workflows where security, auditability, and correctness matter.

Getting started in Cursor

Getting started in Cursor is simple. The Dataverse plugin is available directly from the Cursor Marketplace, making it easy for developers to add Dataverse expertise to their AI coding workflow. Once installed, developers can ask Cursor to connect to Dataverse and the plugin guides the agent through setup, authentication, MCP registration, and environment verification. From there, developers can describe what they want to build or manage in natural language and Cursor can use the Dataverse plugin to route the task through the right tools. The same Dataverse plugin experience is also available for GitHub Copilot and Claude Code, giving developers a consistent way to work with Dataverse across their preferred coding agents.

Setup experience in Cursor:

References

Cursor Marketplace: https://cursor.com/marketplace/microsoft-dataverse

GitHub Copilot: Dataverse | Awesome GitHub Copilot

Claude Code: https://claude.com/plugins/dataverse

Open-source plugin repo: https://github.com/microsoft/Dataverse-skills

The post Dataverse Plugin for Coding Agents Now Available in Cursor Marketplace 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.

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.

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.

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.