Power Apps Delegation Limits Don’t Throw an Error. They Just Give You the Wrong Answer.

Solution architect reviewing a data table dashboard on a large monitor, illustrating enterprise data query review

A finance team at a mid-size distributor built a canvas app to flag overdue receivables. It worked perfectly in every demo. Then it went into production against a SharePoint list that had grown past 4,000 rows, and the “overdue balance” total the app displayed started coming in a little low every week, never wildly wrong, just quietly off by a shrinking or growing margin depending on how the underlying data happened to sort. Nobody got an error message. Nobody got a warning banner in the running app. The gallery rendered, the total summed, and the number was simply incomplete, because Power Apps had silently stopped looking at the data after the first 500 records.

That is the practical shape of a delegation problem, and it is one of the more consequential gaps between how canvas apps behave in the maker’s testing environment and how they behave once real data volume shows up. Power Apps delegation limits determine whether a formula gets pushed down to the data source, which processes it server-side and returns only the matching rows, or whether Power Apps has to pull a bounded chunk of records locally and evaluate the formula against that chunk alone. When delegation fails and the underlying table is larger than the configured limit, the app does not stop working. It keeps working, on a subset of the data, without saying so.

Why Power Apps delegation limits fail silently instead of crashing

A crash gets fixed immediately because someone notices. A silently truncated query gets fixed only when someone happens to reconcile the app’s output against the source system and finds a discrepancy, which in the receivables example took several weeks. For a technical team supporting Dynamics 365 or Power Platform deployments, this is the argument for treating delegation as an architecture decision made at design time, not a performance tweak applied after a slow gallery gets noticed.

The default data row limit in a canvas app is 500 records, adjustable up to a hard ceiling of 2,000 in the app’s Settings under General. Raising that number is a common instinct and a bad one to rely on as a fix, because it just moves the cliff edge further out rather than removing it; a table with 50,000 rows behaves identically whether the limit is set to 500 or 2,000; it only changes how much data has to grow before someone notices something is wrong. Microsoft’s own guidance for this reason recommends the opposite move during development: set the limit down to 1 in a test environment, which forces every non-delegable formula to reveal itself immediately with obviously wrong results, rather than leaving that discovery to production data volume.

What actually gets delegated, and what does not

Power Fx delegates a meaningful set of operations against supported data sources, including Dataverse, SharePoint Online, SQL Server, and Salesforce. Filter, Search, LookUp, and First all delegate, as do the standard comparison operators, And, Or, Not, StartsWith, EndsWith, and the core aggregates: Sum, Average, Min, Max, CountRows, and Count. Sort and SortByColumns delegate as well, with an important caveat covered below for SharePoint. The In operator delegates too, but only against a column on the base table; the moment a formula tests In against a related or lookup column, delegation breaks and the query falls back to local evaluation.

Developer typing Power Fx formula logic on a laptop with a monitor showing abstract code in the background

The non-delegable list is longer and easier to trip over than most makers expect. FirstN, Last, and LastN do not delegate. Neither does If, which means embedding conditional logic inside a Filter predicate is a common way a formula that looks delegable quietly is not. String manipulation functions including Left, Mid, Len, Lower, and Upper are non-delegable, along with Concatenate and the & operator, GroupBy, Ungroup, and type-casting functions like Text and Value. Collect and ClearCollect are non-delegable by nature, since they materialize data locally rather than querying it. A formula like Filter(Fruit, Mid(FruitName, 1, 1) = “A”) looks reasonable and reads cleanly, but because Mid cannot be pushed to the data source, it only ever evaluates against the first page of records pulled locally, meaning a record named “Pineapple” sitting past row 500 will never match a search for names starting with “P,” not because the logic is wrong, but because the function never sees that row.

SharePoint makes this worse than Dataverse does

Anyone who has built canvas apps against both SharePoint lists and Dataverse tables has felt the difference in how forgiving each source is, and the gap is documented, not just anecdotal. SharePoint does not delegate relational comparison operators (less than, greater than, not-equal) on plain text fields at all, only equality. IsBlank does not delegate against text fields either, and the commonly suggested workaround, comparing to Blank() directly, does not behave identically for genuinely empty strings versus null values, which is a subtle correctness gap worth documenting in code review rather than discovering in production.

The bigger gap sits in SharePoint’s complex column types: Choice, Lookup, Person, Group, Task Outcome, Managed Metadata, and External Data. None of these support delegated sorting, so Sort or SortByColumns against a Choice or Person field will silently fall back to sorting only the locally retrieved page. StartsWith does not work against subfields of Choice or Lookup columns. Person and Group fields only delegate on their Email and DisplayName subfields, not on other properties. A set of SharePoint system fields, including ContentType, ModerationStatus, VersionNumber, and several path-related fields, do not delegate under any function at all. UpdateIf and RemoveIf against SharePoint are handled through a batching simulation bounded by the same 500/2,000 record limit rather than a true server-side delegated operation, which matters for any flow that bulk-updates list items from within the app rather than through Power Automate.

Dataverse does not eliminate delegation limits, but it closes most of these specific gaps: relational operators work against text columns, In delegates on base-table columns consistently, and sorting against lookup and choice columns behaves as makers expect. For any canvas app expected to scale past a few thousand records with complex filtering or sorting, that difference is a legitimate factor in the SharePoint-versus-Dataverse decision, not just a licensing or governance one.

Designing around it instead of hoping around it

The most reliable pattern is to push complexity toward the data source rather than the formula bar. Where a filter needs to test a derived value, calculated columns created in Dataverse (or, with more limitation, in SharePoint) let the comparison happen against a pre-computed, delegable field instead of a runtime string function the client has to evaluate locally. Where a search needs to match across multiple text fields, Search() itself delegates and is usually a better first attempt than a hand-built Filter with concatenated conditions, since it is one of the few functions built specifically to delegate substring matching.

For teams supporting these apps in production rather than just building them, the practical safeguard is process, not just formula discipline: run the app with the row limit forced to 1 during test cycles, review any gallery, dropdown, or KPI tile driven by a filter or sort against a table that could plausibly exceed a few hundred rows in production, and treat a yellow delegation warning triangle in Power Apps Studio as a defect ticket rather than a cosmetic nag to dismiss. The warning is not a suggestion about performance. It is Power Apps telling the maker, in the only language it has, that the number on screen may not represent all of the data.

We’ve walked enough Dynamics 365 and Power Platform clients through exactly this kind of discovery, usually during a post-go-live support engagement rather than a planned architecture review, to treat delegation as a first-week design conversation on every canvas app project involving a table that is expected to grow. It is a cheap conversation to have early and an expensive one to have after a finance report has been quietly wrong for a month.

#PowerApps #PowerFx #CanvasApps #Dataverse #SharePointOnline #EnterpriseArchitecture #LowCodeDevelopment

The Power Apps Canvas Authoring Agent Reached GA. Your Governance Policy Didn’t Come With It.

IT governance analyst reviewing AI-assisted low-code application development activity on a large display

A Power Platform CoE lead at a mid-market insurer found out about the change the way most of these things get discovered: by accident, during a routine environment audit. A developer had connected GitHub Copilot to a production canvas app through Microsoft’s new canvas authoring agent, made a dozen edits to a claims-intake screen over an afternoon, and synced them straight into the live coauthoring session. Nothing in the change log flagged it as unusual. The commit history, if you could call it that, lived in a chat transcript on someone’s laptop. No one had done anything against policy, mostly because no policy addressed it.

That gap is the real story behind Microsoft’s canvas authoring agent plugin, which reached general availability in September 2026. The feature itself is a genuine productivity tool: it lets coding agents such as GitHub Copilot and Claude Code create screens, wire up data sources, and write Power Fx formulas inside an existing canvas app, all through a Model Context Protocol (MCP) server that Microsoft ships as part of its Power Platform Skills toolkit. For organizations trying to close the gap between the number of business problems worth automating and the number of qualified makers available to build for them, this closes real ground. What it doesn’t do is arrive with a governance model of its own, and that distinction matters more than the feature announcement lets on.

IT governance analyst reviewing AI-assisted low-code application development activity on a large display

What the canvas authoring agent actually changes

Canvas apps have always been editable from outside Power Apps Studio in a limited sense, through the pack/unpack tooling that Power Platform admins use for source control. What’s new is that an external AI agent can now read and write that same source format, .pa.yaml files that describe screens, controls, and formulas, while a live coauthoring session keeps Studio in sync in real time. A developer opens an app in Studio, turns on coauthoring, points a coding agent at the Studio URL through a short configuration command, and from that point forward the agent can inspect available connectors, understand a data source’s schema, and start proposing changes that appear in the open Studio tab almost immediately.

Microsoft’s own documentation is fairly candid about what this requires from an organizational standpoint. The plugin authenticates through the Azure Identity SDK rather than managing its own credentials, which is the right design choice, but it also means the agent is operating with whatever permissions the signed-in developer already has. There’s no separate, scoped-down identity for “AI agent editing this one app.” If a developer has edit rights across a solution, so does the agent connected to their session.

Why the timing creates a false sense of coverage

Microsoft also shipped enhanced admin controls for agent security this same month, giving Power Platform administrators the ability to centrally define authentication requirements, block anonymous access, and set sharing restrictions for agents at the environment or environment-group level. It’s a legitimate and overdue capability, and if your team has been tracking the Power Platform release notes, it would be easy to assume it covers this new scenario too.

It doesn’t, at least not based on what Microsoft has published. Those enhanced controls are built around agents deployed and run inside the platform itself, the kind built in Copilot Studio and surfaced to end users. The canvas authoring agent plugin is a different animal entirely: a locally running MCP server, invoked from a developer’s own machine, connected to a live editing session rather than a deployed runtime. Nothing in Microsoft’s release plan for the agent security controls mentions third-party coding agents or MCP connections as being in scope. Microsoft’s canvas apps documentation acknowledges the gap in its own way, noting only that “organization policies may restrict agent plugins, third-party MCP servers, local MCP processes.” That’s a pointer toward policies your organization has to write, not a description of controls that already exist.

For a CIO or IT Director, that’s the operative fact. Two features reached general availability in the same release cycle, one of them creates a new pathway for AI-driven changes to production applications, and only one of them comes with a dedicated administrative control surface. The other one inherits whatever governance already existed around app editing generally: your connector policies, your data loss prevention rules, and whatever review discipline your team enforces on its own.

Developer typing on keyboard with dual monitors showing an AI coding agent editing a low-code application interface

What that means for the controls you actually have

None of this means the feature should be blocked outright. It means the governance conversation has to happen at the level of existing controls rather than waiting for a purpose-built one. A few of those controls do real work here if teams actually use them.

Data loss prevention policies still apply to every connector the agent touches, since the plugin operates through the same connector framework as any other canvas app author; an agent can’t reach a data source that DLP policy already blocks for that environment, which means auditing DLP coverage in development environments (where this tool will see the most use) is worth doing before rollout rather than after an incident. Account scoping matters more than usual here too: because the agent inherits the developer’s own permissions rather than operating under a separate identity, the standard advice to use accounts with minimum necessary access for the target app stops being a nice-to-have and becomes the only real access control in play. A developer testing this plugin with an account that has broad maker rights across a solution has effectively given a coding agent the same reach.

Code review is the other lever, and it’s one many low-code teams have historically underused precisely because canvas apps didn’t produce reviewable source in any conventional sense. That’s no longer true. The .pa.yaml output is plain text, which means it can go through the same pull request and review process a development team would apply to any other code change, if the organization chooses to route it that way. Microsoft’s own guidance is explicit that this is a “best-effort” generation process and that validation against organizational standards remains the developer’s responsibility, not something the tooling guarantees. Teams that already treat canvas apps as governed software assets, with source control and change review, will find this capability drops into that process with minimal friction. Teams that have historically treated canvas apps as disposable end-user tools, exempt from the ALM discipline applied to pro-code systems, are the ones most likely to be surprised later.

There’s a narrower risk worth naming directly for security teams: indirect prompt injection. An agent pulling schema information or sample data from a connected source, whether that’s a SharePoint list, a SQL table, or a third-party connector, can encounter content crafted to manipulate its next action. Microsoft flags this explicitly in its own security guidance for the tool, which is a signal worth taking seriously rather than filing away as boilerplate.

The decision in front of you

The practical takeaway isn’t that this feature is unsafe to adopt. It’s that adopting it responsibly requires deliberately extending existing governance rather than assuming new governance arrived with it. That means reviewing DLP policy coverage for the connectors your canvas app makers actually use, tightening account scoping for anyone testing agent-assisted authoring, deciding explicitly whether .pa.yaml changes require the same review your pro-code changes get, and briefing security teams on the prompt injection surface before, not after, the first incident report.

Organizations that have already invested in Power Platform Center of Excellence discipline, source control for canvas apps, and defined review gates will absorb this well. Those still treating canvas apps as a category exempt from that discipline now have a concrete reason to close that gap, because the tooling connecting external AI agents to production apps has already arrived, whether or not the governance model has caught up to meet it. Routeget Technologies has been helping clients build exactly that kind of CoE discipline into their Power Platform environments, and the teams that treat this as an ALM question rather than a feature-adoption question tend to be the ones who avoid finding out about a change during an audit instead of a change request.

#PowerApps #CanvasApps #AIGovernance #LowCodeGovernance #MCPServers #EnterpriseAI

Power Apps Offline Profiles Just Got Easier to Build, Not Easier to Govern

Field service technician using a mobile tablet app in a low-connectivity industrial environment, representing Power Apps offline mode for field workers

A regional field service operation gave its dispatch team the green light to build a canvas app for technicians working in cellular dead zones: rural service calls, basement mechanical rooms, warehouses with concrete walls that killed every signal. The maker who built it, an operations analyst with no formal development background, had the app running offline in an afternoon. No ticket to IT, no admin center request, no waiting on a platform team’s sprint capacity. Three weeks later, a technician’s equipment inspection notes from a Friday afternoon call never made it into Dataverse. The app had been minimized on his phone all weekend while he checked email and texted his dispatcher, and Power Apps only syncs when it is actually running in the foreground. The data was not corrupted or lost outright, but it sat unsynced long enough that a compliance audit flagged a two-day gap in a safety inspection record that mattered.

That scenario is becoming more common, and it traces directly back to a change in how Power Apps offline profiles get created in the first place, a shift most IT organizations have not caught up to yet.

Field service technician using a mobile tablet app in a low-connectivity industrial environment, representing Power Apps offline mode for field workers

Power Apps Offline Profiles Move to Maker Studio

Until December 2025, configuring an offline profile for a Dataverse-backed canvas app meant a trip to the Power Platform admin center. A system administrator or system customizer had to define which tables synced, set filters to control data volume, and manage relationships, all through an admin-only surface that kept offline configuration inside IT’s field of view almost by accident. That friction was never framed as a governance control, but it functioned like one: nothing went offline without someone with elevated permissions touching it first.

Microsoft’s 2025 release wave 1 changes removed that checkpoint. Offline profile creation moved directly into Power Apps Studio, reaching general availability on December 12, 2025. A maker building a canvas app can now toggle “Can be used offline” in the app’s settings, generate a new profile from the app’s existing data sources, and publish, without ever leaving the maker experience or requesting elevated access. Microsoft’s stated rationale is reasonable on its face: reduce dependency on admin resources, shorten the path from idea to working field app, and let the people closest to the operational problem build the solution. For a citizen developer with a genuine business need and no admin relationship to lean on, that is a meaningful unblock.

The Governance Question Nobody Configured

The trade being made here is not really about ease of use. It is about who decides that a given business process is allowed to run detached from the server for hours or days at a time, and who is accountable when that detachment causes a problem. Under the old model, an admin reviewing an offline profile request had at least the opportunity to ask whether a given table should sync offline at all, whether the data involved needed tighter access controls, or whether the use case justified the storage and sync overhead. Under the new model, that opportunity does not exist unless an organization builds a replacement for it.

This is not a hypothetical concern specific to one industry. Any Dynamics 365 or Power Platform environment with field technicians, warehouse staff, inspectors, or delivery personnel is a candidate for exactly the pattern described above: a well-intentioned maker solves a real connectivity problem, and the governance layer that used to exist by default is simply gone unless someone rebuilds it deliberately. Organizations that have invested in a Center of Excellence practice are better positioned here, but a CoE toolkit built around monitoring app creation and DLP policy does not automatically extend visibility into offline profile configuration specifically, since that setting lives inside the app rather than as a separate governed artifact.

IT director reviewing a data synchronization and governance dashboard, representing oversight of Power Apps offline profile configuration

Where the Ceiling Actually Sits

Setting governance aside, the built-in offline engine that now powers this has real technical boundaries that a maker moving quickly can hit without realizing it. Dataverse enforces a hard cap of three million total records synced per offline profile, counting hidden system tables the platform uses internally to support offline mode, and a profile that exceeds it fails to sync rather than degrading gracefully. Each table in a profile is limited to fifteen relationships, only one of which can be a many-to-many or one-to-many type, and an offline profile can include at most fourteen image columns across every table involved. Several capabilities common in online apps simply are not supported offline at all: non-Dataverse connectors such as SharePoint or Excel, virtual and elastic tables, calculated and rollup fields (since there is no client-side engine to reevaluate them), the Relate and Unrelate functions, and self-referential or multi-level relationship lookups.

The foreground-sync behavior that caused the technician’s missing notes in the opening scenario is arguably the most consequential limitation for business planning, because it is invisible until it causes a problem. Power Apps only synchronizes offline data while the app is actively running and the device screen is unlocked. There is no background sync service quietly reconciling data the way a native mobile app with push-based sync might. A field worker who closes the app, locks their phone, or switches to another task mid-shift has effectively paused synchronization, and nothing in the default experience tells them that has happened. For a use case involving safety documentation, chain-of-custody records, or time-sensitive service confirmations, that gap deserves explicit attention before the app reaches production, not after an audit finds it.

A Practical Path Forward

None of this argues for reversing the democratization Microsoft has enabled here; the administrative bottleneck it removed was real; a field team should not wait weeks for a platform team to configure something a maker can now do safely in an afternoon. The more useful response is to treat offline-enabled canvas apps as a specific category worth a lightweight review step, separate from the general app governance an organization already applies. That review does not need to be heavy. It can be as simple as requiring any app with offline mode enabled to pass through a short checklist before it reaches production users: confirming the data involved does not exceed reasonable volume for the sync limits described above, confirming the business process can tolerate the foreground-only sync behavior or has been explicitly designed around it (a startup screen reminder, a manual sync button, a status indicator showing pending changes), and confirming someone owns monitoring the Sync Error table for that app rather than assuming silence means success.

It also means updating whatever Center of Excellence monitoring already exists to specifically flag apps where offline mode has been enabled, since that is now a maker-level decision rather than an admin-level one, and the two are not tracked through the same audit trail by default. An organization that already has DLP policies and environment strategy in place is not starting from zero here, but it should not assume that existing governance automatically covers a setting that used to require an admin’s hands and no longer does.

The underlying capability is genuinely useful, and for the right use case, three weeks of unblocked development against three months of waiting for a platform team is not a close call. The organizations that get real value out of this change will be the ones that pair the speed with a deliberate answer to the question the admin center used to answer by accident: who checks this before it goes to the field. Routeget Technologies has walked several clients through exactly this kind of governance retrofit, and the pattern that works best treats offline enablement as a specific, named checkpoint rather than folding it into a general app review that was never built to catch it.

#PowerAppsOffline #CanvasApps #FieldMobility #CitizenDeveloperGovernance #DataverseSync #PowerPlatformGovernance