Microsoft Power Platform Blog

What’s new in Power Platform: June 2026 feature update

Tiffany Treacy — Thu, 11 Jun 2026 15:31:27 +0000

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:

Get started with the latest updates today!

Jump into Power Apps, Power Automate, and Power Pages to try the latest updates, you can use an existing environment or get started for free using the Developer plan.

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.

Learn more

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.

Learn more

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.

Learn more

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.

Learn more

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.

Learn more

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.

Learn more

Learning updates

Training paths and labs

New

Updated

Power Apps maker

Updated

Power Apps user and mobile

Updated

Power Automate

New

Export OCPM Semantic Model to Fabric Workspace (preview)

Updated

Power Pages

Updated

Power Platform administration

New

Updated

Power Platform developer

New

Updated

Power Platform Connectors

Updated

Custom connectors overview

AI Builder

Updated

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

Bulk Deletion in Microsoft Dataverse: New Capabilities for Data Lifecycle Management

Ritu Joshi — Wed, 10 Jun 2026 15:00:00 +0000

Every Dataverse environment generates data that outlives its usefulness, workflow logs, audit trails, system jobs, plug-in traces, test records, stale transactional data. Left unmanaged, this data accumulates, consumes storage, and eventually forces administrators into reactive, large-scale cleanups.

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:

Does this table accumulate transactional or log data?

How long does the business need to retain this data?

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.

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.

Announcing Low-latency sync for Dataverse to Fabric in GA

Anirudha Bakore — Tue, 09 Jun 2026 14:00:00 +0000

Low-latency sync for Link to Fabric brings significantly faster data replication from Dynamics 365 customer engagement apps and finance and operations apps to Microsoft Fabric. With the Dataverse Link to Fabric, your business data flows directly into Microsoft OneLake — no ETL pipelines, no data duplication, no extra engineering lift. Here’s what makes this a game-changer for AI:

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

Milestone	Timeline	What it means for you
Early release stations	Rolled Out	The rollout begins with early release stations across all geographies.
Europe, Canada, and India expansion	Late June 2026	Availability expands to additional European regions, Canada, and India-based stations
Asia Pacific and UK expansion	Early July 2026	Availability extends across more Asia Pacific regions, including Japan, UAE, Australia, and the UK
Broader Europe expansion	Early – Mid July 2026	Rollout continues across additional North Europe and West Europe stations
Americas and final global expansion	Mid July – End of July 2026	The remaining rollout waves complete across the Americas and other remaining stations
General Availability (GA)	Mid July – End of July 2026	Production-grade release. Every new Fabric Link defaults to low-latency sync from the backend

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

Navigate to the Power Platform admin center.

Set up a new Fabric Link for your Dataverse environment.

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.

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:

Unlink your existing Fabric Link profile.

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

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.

Dataverse MCP Server: Understanding the New Tool Shape

Kent Weare — Mon, 08 Jun 2026 15:51:30 +0000

The Dataverse MCP server continues to evolve. The latest Dataverse MCP updates help agents achieve more with business data through a clearer and more capable tool surface. With these changes, agents can more easily inspect metadata, query records, search across structured and unstructured data, and work with Dataverse data through well-defined tool boundaries.

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:

Tool	Description
`search_data`	Search structured and unstructured data.
`search`	Search table schemas and business skills by keyword.
`create_record`	Inserts a new row into a Dataverse table and returns the GUID.
`update_record`	Updates an existing row in a Dataverse table.
`delete_record`	Delete a row, only after explicit user approval.
`create_table`	Creates a new table with a specified schema.
`update_table`	Modifies schema or metadata of an existing table.
`delete_table`	Deletes a table from Dataverse, only after explicit user approval.
`read_query`	Run supported Dataverse SQL SELECT queries.
`describe`	Get details from search results for tables, records, schemas, skills, and apps.
`upsert_skill`	Add or update a Dataverse skill/playbook.
`delete_skill`	Delete a Dataverse skill/playbook by name.
`init_file_upload`	Generate a SAS URL for file upload.
`commit_file_upload`	Commit a file upload.
`file_download`	Generate a SAS URL for file download.

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:

Enable MCP only for environments where agent access makes sense.
Allow only approved clients.
Understand which tools are exposed.
Treat write-capable tools differently from read-only tools.
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

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

Microsoft Dataverse Plugin: Unleashing Coding Agents on the Enterprise – Microsoft Build 2026

Kent Weare — Thu, 04 Jun 2026 16:00:00 +0000

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:

Maya, a developer building her first data model, app form and view
Riya, a Revenue Ops analyst running her CRM in natural language
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.

Advanced connector policies are generally available

Lane Swenka — Thu, 04 Jun 2026 15:00:00 +0000

Every admin we meet wants the same two things: let their teams build and keep the business safe while they do it. For nearly a decade, data loss prevention (DLP) policies helped you hold that line — sorting connectors into business, non-business, and blocked so that sensitive data and the open internet never met inside the same app or flow. It worked well. But the world your makers operate in has changed.

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.

Learn more

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

Enhanced Data Model and Bootstrap 5 Now Available for Dynamics 365 Portal Templates

Ritwik Ganni — Mon, 01 Jun 2026 12:32:47 +0000

We’re excited to announce that Enhanced Data Model (EDM) and Bootstrap 5 are now available for four key Dynamics 365 portal templates in Power Pages:

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

Open the Power Pages home page.
Select Create a site.
Choose one of the four supported Dynamics 365 templates and select ‘Choose this template’.
Fill in the required details and select ‘Done’.
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.

Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available

Neeraj Nandwana — Fri, 29 May 2026 18:33:02 +0000

We are excited to announce the General Availability (GA) of the Power Pages plugin for GitHub Copilot CLI and Claude Code. Just few months back when we introduced the preview, you could describe a site in natural language and the plugin generated the scaffolding, set up Dataverse entities, wired up the Web API, and deployed the website. We then added server-side logic so your sites could call external services, manage secrets, and run secure business logic.

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.

Agentic authoring with Power Pages Plugin

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.

Skill	Command	What it does
Plan ALM (start here)	`/plan-alm`	Orchestrates the whole process: gathers your promotion strategy and target environments, generates a deployment plan for your review, then runs the other skills in the right order
Set up solution	`/setup-solution`	Creates a publisher and solution and adds your site components
Set up pipeline	`/setup-pipeline`	Configures a Power Platform pipeline from development to your target environments
Configure environment variables	`/configure-env-variables`	Makes site settings environment-specific so each stage gets the right values
Deploy pipeline	`/deploy-pipeline`	Validates the package and runs the deployment, polling until it completes
Export and import solution	`/export-solution`, `/import-solution`	Packages and moves your solution between environments when you need manual control
Diagnose deployment	`/diagnose-deployment`	Surfaces upload and asynchronous errors, matches them to known failures, and offers fixes

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.

Skill	Command	What it does
Security review (start here)	`/security-review`	Orchestrates an end-to-end review across the live site, browser headers, firewall, authentication, and permissions, consolidates everything into one report, then runs the direct skills as needed
Manage firewall	`/manage-firewall`	Turns on the web application firewall (powered by Azure Front Door) to block common attacks such as cross-site scripting, and adds custom IP, country, path, and rate-limit rules to protect a sign-in or sign-up page from brute-force attempts
Manage headers	`/manage-headers`	Reviews the security headers your site sends to browsers and fixes gaps in Content Security Policy, Cross-Origin Resource Sharing (CORS), frame protection, and cookie behavior
Scan site	`/scan-site`	Runs a security scan against your published site and summarizes findings by severity so you know what to fix first
Audit permissions	`/audit-permissions`	Analyzes your table permissions against your code and Dataverse metadata, flagging overly permissive or missing rules

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

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

What’s new in Power Platform: May 2026 feature update

Tiffany Treacy — Thu, 14 May 2026 18:16:52 +0000

Get started with the latest updates today!

Jump into Power Apps, Power Automate, and Power Pages to try the latest updates, you can use an existing environment or get started for free using the Developer plan.

Power Apps

Generally available: Power Fx user defined types (UDTs)

User defined types (UDTs) are now generally available, as of version 3.26044. They are enabled for all new apps and can be enabled for existing apps through settings > updates > new > user-defined types. UDTs are defined with the Type function in the App.Formulas property.

UDTs enable user defined functions (UDFs) to pass complex data structures in and out of your own functions such as records and tables. For example, with the UDT definition Point := Type( { x: Number, y: Number } ); and UDF definition Distance( to: Point, from: Point ) : Number = Sqrt( (to.x – from.x)^2 + (to.y – from.y)^2 );, the formula Distance( {x:0,y:0}, {x:3,y:4} ) returns 5.

UDTs also enable the strong typing of JSON with the ParseJSON function, providing basic data type validation and simplifying coercions. For example, with the UDT definition Person := Type( { Name: Text, Birthday: Date } ); the formula ParseJSON( “{ “”Name””: “”Fred””, “”Birthday””: “”2001-01-01”” }”, Person ) will validate that the birthday is in the proper format and will convert to a Power Fx strongly type date, allowing date functions such as Weekday to be used (for this example, correctly returning 2).

Learn more

Agentic apps

Public preview: custom tools and rich UI for app-based conversations

We’re introducing custom tools and rich UI for app‑based conversations in Power Apps, now in public preview, building on the broader April 2026 updates to Microsoft Power Platform. This release extends how model‑driven apps integrate with Microsoft 365 Copilot, enabling more contextual, visual, and action‑driven experiences that move beyond basic data access toward collaborative workflows inside Copilot.

With this capability, makers can now define custom MCP-powered tools that bring app-specific business logic into Copilot, alongside interactive, Fluent‑based UI widgets that present insights and guide next steps. These components integrate directly into the app’s MCP server and declarative agent, allowing Copilot to dynamically orchestrate actions, combine data, and deliver richer, more guided experiences — all through natural language interactions.

Learn more

AI powered development

Input support for generative pages

Generative pages can now accept context passed in as input, so a page can open already aware of the record the user is working with or any other custom data your scenario needs. That single change unlocks a much broader set of places generative pages can live inside a model-driven app.

Until now, generative pages were primarily limited to standalone, top-level experiences off the sitemap. With input support, you can now launch a generative page from a command bar button, a grid row action, a sub grid navigation, or any other in-app entry point, and the page receives the record context it needs to render the right view.

A few scenarios are still on the way: opening generative pages in side panes, and adding them as tabs or sections within forms via the form designer. We’re working on those for the next quarter.

Other notable improvements

Add an existing generative page to an app: The ‘add a page’ flyout now lets makers pick an existing generative page from the environment instead of always creating a new one, making it easy to reuse a page across multiple apps.
Generative pages in the Power Apps mobile app: Generative pages now display as expected in the Power Apps mobile app. Offline support is not yet available.
Code diff across sessions: The code diff view now works correctly when resuming an editing session, giving makers a continuous view of how a page has evolved across multiple sittings.

Learn more

Migrate your InfoPath forms to Power Platform with coding agents

For years, InfoPath has powered business-critical forms across organizations. With InfoPath now retired, makers face the challenge of opening each .xsn, mapping every control, rewiring every data connection, and recreating every rule by hand.

With the Canvas Authoring MCP Server and the PowerCAT Skill for InfoPath Migration, makers can now use their preferred AI coding agents – GitHub Copilot, Claude Code, or any MCP-compatible assistant – to migrate InfoPath forms into Power Apps Canvas Apps through natural conversation.

The PowerCAT InfoPath Migration Skill teaches your coding agent how to read and interpret InfoPath artifacts. It unpacks the .xsn cabinet, parses the underlying XSN/XSF/XSD definitions, and produces a structured intermediate representation of the form: views, fields, data sources, rules, validations, and submit behaviours. The Canvas Authoring MCP Server then creates appropriate controls, sets properties and formulas, inspects SharePoint lists chosen as the new backing store, and emits structured, validated YAML for each screen. The maker can also continue editing and publishing the app from the Power Apps studio.

Learn more

Building modern apps

Modern control updates for Button, Slider, Icon, and Dropdown with Icon now supporting OnSelect

The modern Button, Slider, Icon, and Dropdown controls are now GA-quality, with focused improvements based on maker feedback. The headline change is OnSelect on the Icon control, one of the most-requested capabilities on modern icon, letting an icon directly trigger actions without overlaying a transparent button. Icons set with OnSelect now render with proper button semantics, including keyboard and screen reader accessibility.

The Dropdown control on desktop now opens a Fluent-themed flyout that matches your app’s visual theme, replacing the browser’s native picker for web. Button and Slider received border, padding, and font property parity with other modern controls. The Slider handle and track render cleanly at all sizes, and Button hover, pressed, and disabled states are visually consistent.

One-click updates on old controls are yet to roll out.

Learn more

Generally available: Grid container with drag-and-drop authoring and full undo/redo

The Grid container control is now generally available. Grid container is the modern, CSS grid–style layout container that replaces heavy X/Y absolute positioning. Makers can define rows and columns and place child controls using Row Start/End and Column Start/End, with span support. This eliminates most container nesting and the formulas previously needed to make canvas layouts responsive.

The GA release includes major authoring improvements shipped over the last several weeks. Makers can now drag controls directly into grid cells, resize controls using span handles, and rely on full undo/redo support for both drag and resize actions. Controls can also overlap temporarily during repositioning, removing the previous forced delete-and-read workflow. Scroll-aware hit-testing means drag interactions work correctly even when the grid scrolls.

Learn more

Public preview: New Data Grid control – a Fluent UI based grid with search, sort, and multi-select for high-density data

The new Data Grid modern control enters public preview as a high-performance, data-dense view for tabular data. Built on Fluent UI, Data Grid supports searchable rows (with a built-in search bar above the grid and a SearchText output property), sortable columns, multi-row selection, and configurable column sub-controls including Text, Number, Phone, Email, URL, and Button column types. Columns are added automatically when you connect a data source, and properties can be unlocked for per-column customization.

Known preview limitations: attachment-type columns from Dataverse are not yet supported, and row virtualization for large datasets is not yet available. Both are planned and coming in the next few weeks.

Learn more

Learning updates

Training paths and labs

Updated training

Power Apps maker

New

Updated

Power Automate

New

Self-healing (preview)

Updated

Power Pages

New

Updated

Power Platform administration

New

Updated

Power Platform developer

New

Updated

Power Platform connectors

Updated

Authenticate your API and connector with Microsoft Entra ID

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

Power Fx: User Defined Types Generally Available

Greg Lindhorst — Wed, 13 May 2026 18:59:00 +0000

User Defined Types (UDTs) are now generally available!

As of Power Apps Studio version 3.26044, UDTs are enabled by default for new apps and can be enabled for existing apps under Settings > Updates > New > User-Defined types.

Enhanced Component Properties, User Defined Functions, and now User Defined Types have all reached general availability and are ready for your production workloads. You now have powerful tools for breaking large, mission critical apps into more modular, error resistant, and maintainable parts.

Records and Tables as parameters and return values

User defined types(UDTs) help make your formulas easier to write and understand by bundling information that logically belongs together into data structures. It also helps your formulas be less error prone by strongly typing information, especially useful when working with JSON.

For example, bundled information on a Book, such as the title, the author, the page count, and the publication year can be grouped together with appropriate types for each element using the Type function in the App object’s Formulas property:

Book := Type( { Title: Text, Author: Text, Pages: Number, Published: Date } );

A book can be passed into a User defined function to be stored in a database:

AddBook( newBook: Book ) : Void = { Collect( Library, newBook ) };

And a table of Books can be returned from a User defined function that filters on page count:

Books := Type( [ Book ] );

FastReads(): Books = Filter( Library, Pages < 20 );

UDTs and JSON

UDTs can be very helpful when working with JSON by validating and converting untyped text into a typed Power F object. For example, JSON has no date/time data type, instead it is stored in a string, often in ISO 8601 format. By providing a UDT, ParseJSON knows it needs to convert the string containing “1902-03-25” into a proper Date value, required by the record passed to AddBook():

AddBook( ParseJSON( "{ ""Title"": ""Hound of the Baskervilles"", ""Published"": ""1902-03-25"" }", Book ) )

If instead, we give ParseJSON a value that it can’t convert, say “03/25/1902” instead, it will generate an error:

AddBook( ParseJSON( "{ ""Title"": ""Hound of the Baskervilles"", ""Published"": ""03/25/1902"" }", Book ) )

Error: Expected value ’03/25/1902′ to be a valid RFC 3339 ‘full-date’ or ‘date-time’ format. Allowed ISO 8601 format(s): ‘YYYY-MM-DD’ …

IsType and AsType

If you’d like finer control over the conversion to a strongly typed value, to first detect and avoid the error, use the IsType and AsType functions. IsType can determine if a Dynamic value is of a particular type without producing an error. For example:

ForAll( ParseJSON( "[ { ""Published"": ""03/25/1902"" }, { ""Published"": ""1902-03-25"" } ]" ), If( IsType( ThisRecord, Book ), AsType( ThisRecord, Book ), Blank() ) )

results in this table, where the missing columns of the valid Book record are filled in with Blank() values:

[ Blank(), { Published:Date(1902,3,25), Title:Blank(), Author:Blank(), Pages:Blank() } ]

RecordOf

Finally, sometimes you have the definition for a table of items, and wish to define a function that takes one of those items as an argument. For example, had we started with the definition of Books (plural):

Books := Type( [ // defines a single column table { // defines a record Title: Text, Author: Text, Pages: Number, Published: Date } ] );

We can define the type for a single book as:

Book := Type( RecordOf( Books ) );

Exactly as we did above, we can use this Book type to define our AddBook function. The definitions of Book and Books here is identical to what we did before – here we started with Books (plural) and above we started with Book (singular).

Let’s go!

Now that UDTs and UDFs are generally available, you can use them with confidence in production workloads. Use them to simplify your formulas and make them more error resistant, especially when working with JSON.

To recap, UDTs are created in the App object’s Formulas property with the Type and RecordOf functions. They are used in UDF definitions (also in App.Formulas) and with the ParseJSON, AsType, and IsType functions.

We’d love your feedback on the Microsoft Power Platform Community Forum where you can also find answers to your questions.

We can’t wait to see what you create!

The post Power Fx: User Defined Types Generally Available appeared first on Microsoft Power Platform Blog.

Microsoft Power Platform Blog

What’s new in Power Platform: June 2026 feature update

Get started with the latest updates today!

Agentic apps

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

AI powered development

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

Power Automate

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

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

Managed platform

Generally available: Advanced connector policies

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

Learning updates

Training paths and labs

Power Apps maker

Power Apps user and mobile

Power Automate

Power Pages

Power Platform administration

Power Platform developer

Power Platform Connectors

AI Builder

Bulk Deletion in Microsoft Dataverse: New Capabilities for Data Lifecycle Management

What is Bulk Deletion?

When should Bulk Deletion be used?

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

Setting a data deletion job

What administrators have been telling us

What’s new

1. Error handling and run visibility

2. Solution-aware bulk deletion jobs

3. Permanent deletion checkbox in the Bulk Deletion Wizard

4. Engine refinements and a new sandbox deletion mode

Bulk Deletion keeps a Dataverse environment healthy

Announcing Low-latency sync for Dataverse to Fabric in GA

The challenge: data freshness matters

What is Low-latency sync?

Under the hood: fewer hops, better reliability

What this means for your team

Performance at a glance

Tentative timelines

Prerequisites for Finance and Operations

How to get started

How to confirm low-latency sync is enabled

What about Synapse Link and Export to Data Lake?

Looking ahead

We want your feedback

Dataverse MCP Server: Understanding the New Tool Shape

What changed

Why the tool shape matters

A practical example

Governance still matters

Summary

Additional resources

Microsoft Dataverse Plugin: Unleashing Coding Agents on the Enterprise – Microsoft Build 2026

Scenario 1: Zero to App in One Session

Scenario 2: Talk to Your CRM in Plain English

Scenario 3: Manage Your Environment Like a Pro

Three Users, Three Jobs, One Unified Approach

Advanced connector policies are generally available

Governance built for how people actually work today

What changes with ACP

Where ACP shines: scalability

The shift to earlier feedback

What comes next

Getting started

Enhanced Data Model and Bootstrap 5 Now Available for Dynamics 365 Portal Templates

What’s new

Why this matters

How to get started

Prerequisites

Create a new site

Learn more

Build Power Pages Sites with AI through Agentic Coding tools, now Generally Available

What’s new at GA

Move to production with ALM and pipelines

Secure your site for production

Set up authentication and access

You stay in control