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

What Actually Breaks First in a Power Apps Code Apps Rollout

Developer reviewing a Power Apps code app in a code editor next to a web application preview

A team at a mid-market manufacturer spent three weeks building their first Power Apps code app: a React front end wired to Dataverse through the generated TypeScript services, styled with Fluent UI, running clean in local development. The day they pushed it to their first pilot users, the app loaded, authenticated through Microsoft Entra ID without a single line of auth code, and then silently failed to render three of its five widgets. The culprit wasn’t a bug in their code. It was a tenant-wide Content Security Policy that Microsoft had already turned on weeks before their app was even scaffolded, quietly blocking every request to a domain outside the Power Apps allowlist. Nobody on the project had heard of it, because nobody had read the message center post that announced it.

That kind of surprise is a fair preview of what a Power Apps code apps rollout actually looks like right now. Since February 5, 2026, Power Apps code apps have been generally available, letting developers build full front-end web applications in React or Vue inside a code-first IDE like Visual Studio Code, then run and host those same apps inside the managed Power Platform, with the platform handling authentication, connector access, and lifecycle management underneath. For architects who have spent years explaining why a canvas app can’t do what a pro-code team needs, this closes a real gap. GA status makes it easy to underestimate three things that behave nothing like a typical canvas app rollout, though: a content security policy that was already enforcing before most organizations had even piloted the feature, a licensing model built around Premium seats rather than the cheaper per-app plan many teams still lean on for canvas apps, and an ALM story that looks familiar until you notice which pieces are missing.

The CLI Workflow, In Practice

A code apps project starts from the pac code command group in the Power Platform CLI rather than from the maker portal. After scaffolding a project (Microsoft’s own quickstart pulls a Vite template via degit), pac code init --displayname "App Name" registers the app against an environment and writes a power.config.json file tying the local project to that registration. Adding a Dataverse table as a data source looks like this:

pac code add-data-source \
  -a "shared_commondataserviceforapps" \
  -c "<connection-id>" \
  -t "accounts"

That command handles the unglamorous but genuinely useful part of the job: it generates a typed service class in ./generated/services/, so the resulting TypeScript reads like AccountsService.getall() and AccountsService.create({ name: "Contoso Ltd" }) rather than hand-rolled HTTP calls against the Dataverse Web API. The connection itself, though, has to already exist in make.powerapps.com. The CLI wires up access to an existing connector connection; it does not create one. That means whoever owns the pilot needs a connections strategy in place before a developer ever opens an editor. Once the app is built, npm run build followed by pac code push ships it to the platform, where it inherits the same sharing limits, quarantine behavior, and Conditional Access controls that already govern canvas apps in that environment.

That inheritance is the real point of running code apps inside Power Platform instead of standing up a bespoke Azure Static Web App: Data Loss Prevention policies still apply at runtime, tenant isolation and Azure B2B rules still apply, and the app shows up in Power Platform Monitor for health telemetry the same way any other maker-built app would. None of that governance has to be rebuilt by hand.

Developer working on a code apps project across two monitors showing a code editor and a web application preview

Where the CSP Wall Actually Sits

Microsoft began enforcing a strict Content Security Policy against code apps in two stages: introduction on January 26, 2026, and full enforcement on January 30, 2026, communicated through message center post MC1218747. Past that date, any request a code app makes to a domain outside the Power Apps allowlist gets blocked by default, silently, at the browser level. The app itself keeps running. It’s the fetch calls to a third-party API, the image tags pointed at an external CDN, or a web font loaded from outside Microsoft’s own domains that quietly stop resolving, which is exactly the kind of failure that reads like a rendering bug rather than a policy block until someone actually opens the browser console.

The fix isn’t difficult, but it has to happen before a real rollout rather than after users start filing tickets. Microsoft’s own guidance describes a five-step sequence: temporarily disable the “Enforce content security policy” setting in the Power Platform admin center, turn on CSP reporting instead, exercise the app enough to surface every external domain it actually calls, add those domains to the allowlist, and only then re-enable enforcement. Skip the reporting step and jump straight to a hand-built allowlist, and a team ends up chasing one broken image or one failed API call at a time, across three environments, for weeks.

The License Model Nobody Priced In

The other assumption worth checking before a pilot expands past a handful of users is licensing. Microsoft’s documentation is specific on this point: end users running a code app need a Power Apps Premium license, full stop. That catches teams who assumed code apps would ride along on whatever licensing already covers their canvas apps, particularly organizations that still lean on the per-app plan for cost control. That plan is in the middle of its own wind-down: as of January 2, 2026, it’s no longer available for purchase by new customers, though existing Enterprise Agreement and Cloud Solution Provider customers can keep renewing it under current terms, and MPSA customers get a 60-day migration window after their agreement ends. None of that grandfathering helps a team piloting code apps for the first time this year, because a per-app license was never going to cover a code app to begin with. The practical move for an architect scoping a rollout is to put the Premium requirement into the business case during the first conversation with finance, not to let it surface when the pilot tries to onboard its fifteenth user.

What ALM Actually Covers, and What It Doesn’t

Solution architects evaluating code apps for a broader rollout should also be honest about what doesn’t carry over from the rest of the Power Platform toolbox. Native Power Platform Git integration doesn’t support code apps today, so a team can’t rely on the same solution-based source control workflow it might use for a model-driven app. The practical workaround is treating the code app’s own repository as the system of record and running a standard CI pipeline against it, GitHub Actions calling pac code push after a build step is a common pattern, rather than expecting Dataverse solutions to manage the app’s lifecycle end to end. Code apps also can’t run offline, aren’t supported in the Power Apps app for Windows, don’t support Secure Implicit Connections, and can’t be embedded inside other app types except through a Power BI Visual. For a field service scenario that genuinely needs offline capability, or a mobile-first workflow, this rules code apps out entirely. They’re built for client-side, standalone, always-connected line-of-business scenarios, and treating them as a drop-in replacement for every canvas app on a roadmap produces a project that fights the platform instead of one that benefits from what GA actually delivered.

Solution architects reviewing a governance and security policy dashboard in a meeting room

Planning a Power Apps Code Apps Rollout

None of this argues against adopting code apps. It argues for sequencing the rollout the way any new application platform deserves, rather than the way a low-code feature update usually gets treated. Before the first pilot ships to real users, confirm the environment has code apps enabled deliberately, through Settings, Product, Features, rather than left to whichever admin happened to click through a prompt. Run the CSP disable-report-allowlist-reenable cycle against the actual pilot app, not a hello-world sample that calls no external services and tells an architect nothing useful. Get Premium licensing into the cost conversation before the user list grows past the pilot group, not after. And decide early which category of app actually belongs here: a case-management tool for an internal finance team, wired to Dataverse and a couple of line-of-business connectors, is a strong fit. A field technician’s offline inspection app is not, regardless of how appealing the React tooling looks to the team building it.

Code apps are a genuine expansion of what Power Platform can host, and for organizations with pro-code developers sitting next to citizen developers, they finally give both groups a shared platform instead of two disconnected ones. Getting there without a production incident, though, means treating the CSP policy, the licensing model, and the ALM gaps as part of the architecture decision, not as details to sort out after the first app is already live. Routeget’s team has walked several clients through exactly this sequencing on early code apps pilots, and the pattern holds: the rollouts that go smoothly are the ones where governance and licensing get scoped in the same week as the first line of code, not after the first support ticket comes in.

#PowerAppsCodeApps #PowerPlatformGovernance #PowerAppsLicensing #ContentSecurityPolicy #PowerPlatformALM #EnterpriseAppDev

The Power Platform CoE Starter Kit Is No Longer Maintained. Here’s What Actually Replaces It.

IT governance director reviewing a Power Platform tenant governance dashboard on an office display

An IT Director at a mid-size manufacturer pulled up her Power Platform governance dashboard last month expecting the usual weekly refresh: new app registrations, a handful of DLP policy violations, a queue of flows awaiting review. Instead she found version numbers that hadn’t moved since February. The Center of Excellence Starter Kit her team built three years ago, the tool that had quietly governed more than 400 apps and flows across the tenant, had gone dormant. Nobody had announced a shutdown. It simply stopped getting updates, and the team only noticed because a routine compatibility check flagged an error the kit’s outdated code couldn’t handle.

That scenario is playing out across a lot of Power Platform tenants right now, because Microsoft has quietly, officially confirmed that the Power Platform CoE Starter Kit is no longer being actively maintained.

IT governance director reviewing a Power Platform tenant governance dashboard on an office display

What Changed With the Power Platform CoE Starter Kit

The language matters here, because a lot of the discussion around this shift has overstated what happened. Microsoft’s own documentation, updated April 30, 2026, states plainly that the Power Platform CoE Starter Kit is no longer actively maintained: issues submitted against the GitHub repository are no longer reviewed, and any genuine security concern should now be routed to the Microsoft Security Response Center rather than the project’s issue tracker. Monthly releases, which had shipped reliably in the first week of nearly every month for years, stopped after February 2026.

That is not the same as a retirement. Microsoft has not published an end-of-life date, has not blocked new deployments, and explicitly states the kit “remains available for both new and existing deployments.” Organizations running it today won’t wake up to a broken environment. What they will face, gradually, is a governance tool that stops keeping pace with platform changes: new connector types it doesn’t recognize, new environment settings it can’t report on, and eventually compatibility issues with Dataverse or Power Automate updates that nobody is fixing on the other side. For a CIO, this is a slower and in some ways more dangerous problem than a hard cutoff, because there’s no forcing deadline to put a migration project on the calendar.

The Native Replacement Microsoft Is Building

Microsoft’s stated direction is to fold CoE-style governance directly into the Power Platform admin center rather than leaving it to a community-maintained Dataverse solution. Four capabilities make up that shift, and they’re at different stages of maturity, which matters for anyone trying to plan around them.

Inventory gives tenant-wide visibility into every app, flow, and now agent across the organization, replacing one of the CoE kit’s original core functions: knowing what exists. Usage entered public preview on February 13, 2026, and Microsoft has targeted general availability for August 2026; it tracks adoption patterns, surfaces top resources and their owners, and sits in the licensing and capacity category of the admin center, which is a signal about where Microsoft sees the primary value: helping organizations understand what they’re actually consuming before a renewal conversation. Monitor, focused on detecting operational health issues across Power Platform resources, entered public preview in August 2026 with no GA date yet confirmed. And Actions, sometimes referred to as Power Platform Advisor, organizes personalized recommendations into four categories: security, operational efficiency, licensing and capacity, and performance, with the ability to remediate inline, automate a fix through Power Automate or PowerShell, snooze non-security items for up to two months, and share a recommendation into Teams for follow-up.

Separately, Microsoft previewed the concept of an “Agentic Center of Enablement” entering public preview in July 2026, framed as a longer-term, AI-driven successor to the CoE model built for a world where agents, not just apps and flows, need governance. It’s worth watching, but it is a preview-stage concept today, not something to build a 2026 governance budget around.

Solution architect reviewing a cloud governance and inventory dashboard alongside code at a dual-monitor workstation

Where the Native Tools Still Fall Short

None of this means the admin center is a drop-in replacement yet, and CIOs who treat it as one will find gaps. Partner analysis from governance specialists who have compared the two toolsets in detail, most notably Rencore’s review of the transition, points to real coverage gaps: shadow IT detection, the app and flow lifecycle and ownership-transfer workflows that let a departing employee’s assets get reassigned cleanly, visibility that spans multiple tenants for organizations with a multi-tenant structure, tracking of DLP policy violations across environments over time rather than as a point-in-time snapshot, and analysis of connector misuse or risky customization patterns. Those were never edge-case features in a mature CoE deployment; they were often the reason the kit got built in the first place.

This is the practical takeaway for anyone budgeting a governance program this year: the native tools are genuinely useful and getting better on a defined Microsoft release cadence, but they are not yet a full substitute for a well-built CoE kit deployment, particularly on the lifecycle and cross-environment tracking side.

What This Means for Budget and Governance Planning

The right response isn’t a rushed migration off the CoE kit, and it isn’t ignoring the situation either. A few decisions are worth making deliberately rather than by default. First, audit what your current CoE deployment is actually doing for you today: which dashboards get used weekly, which automated flows are load-bearing for compliance reporting, and which components have quietly gone unused since they were set up. Second, map that list against the admin center capabilities on their current timeline: Usage moving to GA in August 2026 is close enough to plan around now, while Monitor and the Agentic Center of Enablement are still preview-stage and shouldn’t be treated as committed infrastructure for this fiscal year. Third, price in the hidden cost most organizations forget: the CoE kit runs in its own dedicated Dataverse environment with its own capacity and maintenance overhead, and if native admin center tools can absorb even part of that workload, there’s a real capacity and licensing saving on the table, separate from the governance question entirely.

Finally, don’t assume the gap-filling has to be all-or-nothing. A common pattern emerging among organizations further along in this transition is a hybrid model: keep a thinned-down CoE kit running specifically for the lifecycle, ownership-transfer, and cross-environment tracking that Microsoft hasn’t natively replaced yet, while shifting license and capacity monitoring, security recommendations, and day-to-day operational health checks over to the admin center as those features reach general availability. That approach avoids both extremes: clinging to an aging toolkit out of inertia, or ripping out functioning governance infrastructure before its replacement is actually ready.

There’s also a licensing angle worth surfacing to a CFO, not just an IT Director. Because Usage sits in the admin center’s licensing and capacity category, it’s designed to answer a question most Power Platform tenants can’t currently answer with confidence: which licensed users, premium connectors, and per-flow capacity allocations are actually driving cost, and which are legacy grants nobody has revisited since a pilot project ended two years ago. A CoE kit deployment can surface some of this with custom Power BI reporting built on top of it, but that reporting has to be built and maintained by someone. Getting the equivalent view natively, once Usage reaches general availability, removes a maintenance burden that a lot of governance teams have been quietly carrying for years without budgeting time for it.

The Takeaway for IT Leadership

Governance programs built on the CoE Starter Kit haven’t failed and don’t need to be dismantled this quarter. But they do need a documented transition plan, because “no longer actively maintained” is Microsoft’s way of saying the clock is running even without a published deadline. Organizations that treat this as a planning input now, rather than an emergency later, will have the easier migration. We’ve helped several clients work through exactly this kind of platform transition, mapping existing governance investments against Microsoft’s native roadmap so nothing gets rebuilt twice, and it’s a conversation worth having before a compliance audit forces it.

#PowerPlatformGovernance #CoEStarterKit #DataLossPrevention #LicenseOptimization #PowerPlatformAdmin #EnterpriseAI