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.

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

What’s new at GA

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

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

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

Move to production with ALM and pipelines

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

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

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

Secure your site for production

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

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

Set up authentication and access

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

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

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

You stay in control

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

Get started

Install or update the plugin and PAC CLI

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

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

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

We are looking for your feedback

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

Resources

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

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

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.

The Problem with Agentic Administration Today 

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

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

What is Dataverse Admin Skills?  

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

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

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

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

The agent responds: 

1. Lists your Dataverse environments 

2. Filters for environments starting with “Preprod” 

3. Asks you to confirm the list 

4. Updates each environment in parallel 

5. Shows you a summary table of what changed 

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

What’s Available Now and Coming Soon

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

Get Started and Try it out in three simple steps

Step 1: Install the plugin 

GitHub Copilot (VS Code):

 /plugin install dataverse@awesome-copilot

Claude Code: 

/plugin install dataverse@claude-plugins-official

Step 2: Try it 

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

Step 3: Test the scenarios 

Settings management: 

• “Is auditing enabled on my dev environment?” 

• “Enable auditing on all my developer environments” 

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

Bulk delete: 

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

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

• “Pause the bulk delete job with ID …” 

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

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

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

Here’s what’s new for each persona: 

• For business users, business data in Microsoft 365 Copilot. Your unified business data includes Dynamics 365 or custom apps built in Power Platform powered by Dataverse combined with Microsoft 365 data (i.e. emails, meetings, and documents) to deliver grounded, contextual answers.  

• For makers, business skills describe a specific process. Skills are the detailed steps-by-step instructions involved, the information required, and the business rules that apply. Agents connected to the Dataverse MCP server discover relevant skills automatically and use them to complete tasks according to your organization’s standards.  

• For developers, Dataverse Plugin for coding agents. Dataverse plugin is an open-source plugin that lets AI coding agents like Claude Code and GitHub Copilot build and manage Microsoft Dataverse solutions through natural language. Available on Claude Marketplace: install a plugin, say “connect to Dataverse,” and start building. 

Here’s what we shipped and why it matters. 

Dataverse in Microsoft 365 Copilot

Business data has been locked behind app-specific experiences. Business users context switch between Dynamics 365, Power Apps, Outlook, and Teams to piece together the full picture. What if Copilot could understand your business data the way your best people do? 

That’s now happening. In March, we announced Microsoft 365 Copilot embedded as an in-app sidecar experience within Power Apps, Dynamics 365 Sales, and Dynamics 365 Customer Service. Under the hood, we introduced a reasoning layer natively integrated in Microsoft 365 Copilot, reconciling enterprise data and work signals from across your apps to power the combination of critical sources of business data and insights: Microsoft 365 apps, Dynamics 365 apps, and Power Platform. Coming soon in early June, business data will be available across Microsoft 365 Copilot experiences in Copilot App on desktop, Teams, Outlook, Word, Excel, and PowerPoint.

What does this look like in practice? Ask Microsoft 365 Copilot “There’s new guidance about vendor selection. For overdue issue, please select which vendor to assign” and get a precise list grounded in your CRM records and email signals. No report building. No app switching. No guesswork. Let’s see this in action. 

By leveraging the intelligent semantic layer in Agentic AI powered Dataverse Search, Microsoft 365 Copilot experiences deliver answers using an adaptive reasoning process based on schema and keywords. This allows Microsoft 365 Copilot to understand tables and relationships and how to navigate them to get the right answers rather than doing just keyword search. 

The same proven unified semantic search index that powers global search in Power Apps also provides retrieval and grounding for Copilot, agents, and MCP tools. When your search gets better, every AI experience built on it gets better too. In this release, we’ve made the index faster, more real-time, and easier to manage: 

• Up to 6× faster initialization. Turning on Dataverse search for a new environment now takes minutes, not hours. Your team gets started faster, so they can build more.  
• Near real-time data freshness. Newly added or updated records appear in Copilot results within minutes. Copilot and agents are ground on current business data, not stale snapshots. 
• Zero-disruption schema evolution. Adding or removing columns no longer pauses indexing. Schema changes refresh in the background while Dataverse Search keeps running. 
• Visibility and control for admins. See exactly which tables are indexed, how much capacity each consumes, and download usage reports. Enable or disable indexing for Copilot and search independently, so you can scale AI workloads without impacting existing search behavior. 

One search index for Copilot, agents, and MCP. All grounded in the same governed business data in Dataverse. 

Business skills: teach agents how your organization works 

Your organization’s most valuable knowledge lives as tribal knowledge in people’s heads: the escalation path for a vendor issue, the approval steps for a sales proposal, the process to assign the right specialist to staff your project. Agents can’t access what isn’t simply written down. 

Business skills in Dataverse, now in public preview, captures your processes, policies, and domain expertise as natural-language instructions. Makers can write business skills in plain language or upload existing skills and govern them with built-in controls. The best part: any agent connected to the Dataverse MCP server discovers your skills automatically, whether it runs in Copilot Studio, GitHub Copilot, Azure AI Foundry, or any MCP-compatible client. Define once, apply everywhere – let’s see this in action.  

Velrada makes this real in a field service inspection scenario: 

“Velrada built Inspection Agent to help worksite supervisors and field workers track the maintenance status of their equipment – so they can trust the tools used to get the job done. The Inspection Agent uses business skills to perform an equipment inspection with the user. For an onsite HVAC inspection, the Inspection Agent will invoke the business skill to determine the questions to ask based on equipment class, checks the last inspection outcomes, and pull in context of any historic issues. The result: a conversational assessment that produces a consolidated inspection report on the HVAC unit’s condition and follow-up guidance for maintenance” 

— Matthew Pontel, General Manager of Applied AI, Velrada 

Learn more about business skills: Introducing business skills: Teach agents how your organization works  – Microsoft Power Platform Blog 

Dataverse plugin: coding agents now speak Dataverse 

Enterprise development is shifting from writing code to directing AI agents. Developers describe intent; coding agents orchestrate the right tools over governed business data. What used to require juggling APIs, CLIs, and documentation can now be expressed as a single prompt. 

The Dataverse Plugin for coding agents (in public preview) makes this real. Install one open-source plugin, and your coding agent gets full Dataverse fluency. Under the hood, the plugin packages four tools and knows which one to reach for:  

• Dataverse MCP Servers for ad-hoc discovery and natural-language queries. 

• Dataverse CLI (in preview) for rich data plane actions. 

• Python SDK for batch and scripted operations. 

• PAC CLI for admin gestures like solution export and environment management. 

No manual setup. Describe your intent; the agent handles the orchestration. See this in action. 

Picture this: a platform developer needs to build a customer escalation tracker on Dynamics. With the Dataverse plugin for coding agents, they connect to their environment, create tables, define business skills, configure security roles, and deploy the solution, all through natural language in their coding agent. That’s modern development with coding agents. 

Get started: Install the Dataverse Plugin 

Dataverse agentic evolution: from experimentation to execution 

Six months ago, agents could access your data. Today, they understand your business: your schema, your processes, your rules. The wall between data access and business understanding is coming down: that’s the agent data platform. Today at EU Biz Apps Summit in Cologne, we’re showing all of this live. And we’re just getting started. At //Build in June, we’ll share what’s next. Learn more:  

• Business Skills blog: http://approjects.co.za/?big=en-us/power-platform/blog/2026/05/01/business-skills/ 

• Sample Business Skills on Github: https://github.com/microsoft/dataverse-business-skills

• Dataverse + M365 Copilot blog: Build business understanding with Dataverse in Microsoft 365 Copilot – Microsoft 365 Developer Blog 

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

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

• Dataverse Plugin blog: https://devblogs.microsoft.com/powerplatform/dataverse-plugin-claude-marketplace/ 

• Dataverse Search docs: http://approjects.co.za/?big=en-us/dynamics-365/blog/it-professional/2025/12/08/agentic-ai-dataverse-search/ 

The post Dataverse Is Your Agent Data Platform: Here’s What’s New  appeared first on Microsoft Power Platform Blog.

Business skills: Process knowledge that agents can follow 

Business skills in Dataverse are now in public preview! You can capture your organization’s processes, policies, and domain expertise as natural-language instructions that AI agents discover and follow at runtime. 

Each business skill describes a specific process — the detailed steps-by-step instructions involved, the information required, and the business rules that apply. Agents connected to the Dataverse MCP server discover relevant skills automatically and use them to complete tasks according to your organization’s standards. 

Because skills are defined once and stored centrally in Dataverse, any agent can use them — whether it’s running in Copilot Studio, GitHub Copilot, VS Code, Azure AI Foundry, or any MCP-compatible client. When multiple agents reference the same skill, they follow the same process. Update the skill, and the change applies everywhere — no need to track down and patch individual agent configurations.

Skills are fully governed with built-in sharing and visibility controls, and they’re solution-aware — which means you can add them to your power platform solutions and move them across environments as part of your existing ALM process. 

Seeing it in action 

Previously, asking an agent to follow a multi-step business process — like assigning vendors to open issues — meant the agent had no context for how your team actually handles that work. The result was generic at best and unable to adapt to the changing processes. 

With business skills, the same request produces a precise, grounded result. The agent discovers the relevant business skill, follows your documented process step by step, and completes the task across your Dataverse data — no custom code, no workflow builder, no app switching. 

Create, share, and govern — all from Power Apps 

Business skills live in Dataverse and you can manage them from make.powerapps.com. Write your process in natural language or upload existing documentation, share it with the right people, control who can see and edit it, and deploy it across environments through solutions — all without leaving Power Apps. Update a skill and every connected agent picks up the change immediately, no republishing required.

Prefer to work conversationally? The Dataverse MCP server lets you create and update skills by simply asking an agent. 

Who should use business skills? 

Business skills capture domain specific tasks from existing business workflows as context to further inform Copilot and agents. Whether you’re a maker codifying how your team operates, an agent builder who needs agents to follow real processes instead of generic instructions, or an admin who needs governance over how business knowledge is shared and deployed — business skills are built for you. 

Velrada enables consistent process execution for equipment inspections

Matthew Pontel, General Manager of Applied AI at Velrada remarks that “Velrada built Inspection Agent to help worksite supervisors and field workers track the maintenance status of their equipment – so they can trust the tools used to get the job done.

The Inspection Agent uses business skills to perform an equipment inspection with the user. For an onsite HVAC inspection, the Inspection Agent will invoke the business skill to determine the questions to ask based on equipment class, checks the last inspection outcomes, and pull in context of any historic issues. The result: a conversational assessment that produces a consolidated inspection report on the HVAC unit’s condition and follow-up guidance for maintenance.”

Get started 

Business skills bring your organization’s expertise to every agent — no code, no complex tooling, just your processes written in plain language and available wherever agents run. We invite you to: 

1. Enable Dataverse intelligence in the Power Platform admin center. 

2. Navigate to the  Business skills page in Power Apps from the left pane. 

3. Create your first skill or upload an existing skill. 

4. Connect an agent to the Dataverse MCP server and see it in action. 

Want a head start? The sample business skills repository on GitHub includes production-ready examples you can install directly in your environment. 

Try the preview today — we can’t wait to see what you build. Learn more with additional resources: 

• What is Dataverse intelligence? 

• Business skills overview 

• Create and use business skills 

• Sample business skills on GitHub 

The post Introducing business skills: Teach agents how your organization works  appeared first on Microsoft Power Platform Blog.

Meet /add-server-logic, /add-cloud-flow, and /integrate-backend – three skills that complete the application stack. They build on an already working site by introducing secure server-side logic, Power Automate cloud flows, and intelligent backend orchestration for end-to-end functionality.

What’s new

• /add-server-logic generates secure server-side JavaScript endpoints for validation, secret management, external API calls, and cross-entity operations.
• /add-cloud-flow integrates existing Power Automate cloud flows into your Power Pages site for approval workflows, notifications, and scheduled automation.
• /integrate-backend analyzes your prototype, determines the right approach (Web API, Server Logic, and/or cloud flow) for each feature, and orchestrates the complete build sequence.

/add-server-logic: secure server-side endpoints, generated end to end

Server Logic in Power Pages moves critical operations from the browser to the server for improved control, scalability, and security. It’s generally available, so it’s fully supported for production workloads. With server logic, your site can perform complex tasks and integrations without exposing sensitive logic or data on the client side. Server logic enables you to:

• Connect to external services. Integrate securely with REST APIs, Azure Functions, or other business systems, e.g., call the Stripe API to process a payment without exposing your API key. (Tutorial: interact with external services)
• Perform secure data operations. Query, update, or delete Dataverse records with consistent server-side validation, e.g., check inventory levels before accepting an order submission. (Tutorial: interact with Dataverse tables)
• Run custom logic. Calculate totals, enforce business rules, or enrich data with external lookups before returning results, e.g., aggregate data across multiple tables into a single global search response.
• Manage secrets server-side. Store credentials and API keys on the server, never in client code, e.g., authenticate with Microsoft Graph to upload documents to SharePoint. (Tutorial: interact with Microsoft Graph and SharePoint)

The /add-server-logic allows you to describe what you need in plain language, and it generates the server-side endpoint, web role assignments, table permissions, a typed client-side service, and component updates.

Here’s an example. Say your order form needs to validate inventory before accepting a submission:

You: "/add-server-logic Add validation that rejects orders when quantity exceeds inventory"

Plugin:
        → Creates server-logic/validate-order.js (server-side endpoint)
        → Assigns Authenticated Users web role
        → Verifies table permissions for cr_inventories
        → Creates src/services/serverLogic/validateOrder.ts (typed client)
        → Updates OrderForm.tsx to call validateOrder() before submit

Or say your site needs a global search that queries across multiple Dataverse tables (products, orders, and knowledge articles) and returns unified results. That kind of cross-entity aggregation can’t run from the browser in a single call:

You: "/add-server-logic Add a global search endpoint that searches across products,
      orders, and knowledge articles and returns combined results"

Plugin: 
        → Creates server-logic/global-search.js (server-side endpoint)
        → Queries cr_products, cr_orders, and cr_knowledge_articles
        → Aggregates and ranks results server-side
        → Assigns Authenticated Users web role
        → Verifies table permissions for all three tables (Read)
        → Creates src/services/serverLogic/globalSearch.ts (typed client)
        → Updates SearchPage.tsx to call globalSearch() on input

Before generating any code, a built-in Server Logic Architect agent analyzes your use case and presents a proposal for your review.

/add-cloud-flow: Power Automate integration from your site

Not everything belongs in a server-side endpoint. Approval workflows, email notifications, and event-driven automation are better suited to Power Automate cloud flows. The /add-cloud-flow skill integrates an existing cloud flow into your Power Pages site. It does not create new cloud flows. You build the flow in Power Automate, and the skill handles the integration: registering the flow with your site, generating the client-side code to trigger it, and wiring up data exchange between the page and the flow.

You: "/add-cloud-flow Connect the supplier approval flow to my application page"

Plugin: 
        → Registers the existing cloud flow with your site
        → Generates client-side code to trigger the flow
        → Handles async workflow state and callback patterns

Whether it’s a manager approval step, an order confirmation email, or a nightly data sync, /add-cloud-flow handles the integration so you focus on the business process.

/integrate-backend: let AI choose the right approach

Start here if you’re not sure whether a feature needs Web API, Server Logic, or a cloud flow. /integrate-backend acts as your server-side architect. It analyzes your website, determines the right approach for each feature, and orchestrates the plugin skills to build everything in the correct order.

Take a supplier portal with product listings, order submission, a global search across products and orders, and an invoice approval workflow. Without /integrate-backend, you’d need to figure out that product listings are standard CRUD (Web API), global search requires cross-entity aggregation on the server (Server Logic), and invoice approvals need a multi-step flow (Power Automate). You’d also need to sequence the work: Dataverse tables before Web API, web roles before Server Logic, authentication before server-side endpoints.

The /integrate-backend skill automatically scans your entire website and recommends relevant business processes.

You: /integrate-backend

Plugin:
  ANALYSIS
  ════════
  #   Feature              Approach         Reason
  1   Product listings     Web API          Standard CRUD on cr_products
  2   Order submission     Server Logic     Inventory validation + transaction
  3   Global search        Server Logic     Cross-entity aggregation on server
  4   Invoice approvals    Cloud Flow       Multi-step approval workflow

How it works

Every skill follows a propose-then-build workflow. An AI architect agent analyzes your request, designs the solution, and presents it for approval. No code is generated, and no infrastructure is created until you approve. This keeps you in control while eliminating manual configuration.

The decision framework is simple:

• Server Logic. Secrets or API keys, server-side validation, multi-table transactions, external or on-premises service calls, cross-entity search, rate limiting, or Dataverse plugin invocation.
• Cloud flow. Approval workflows, notifications, or scheduled processing.
• Web API. Everything else (standard CRUD operations).

Benefits

• Enhanced security. Business logic, secrets, and API keys stay on the server and are never exposed in the browser.
• Reduced manual configuration. Each skill generates endpoints, permissions, typed services, and component updates end to end.
• Intelligent approach selection. /integrate-backend determines whether each feature needs Web API, Server Logic, or a cloud flow, so you don’t have to.

Get started

Install or update the plugin and PAC CLI

Install the latest plugin and PAC CLI, as both are required. Server logic support was introduced in the latest PAC CLI release, so older versions will not work with /add-server-logic. For the easiest setup, use Quick Install (recommended), which installs all Power Platform plugins, updates PAC CLI, and enables auto-update.

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.

The post Build your server-side logic with AI: new Power Pages Agentic Code skills appeared first on Microsoft Power Platform Blog.