Today I’m sorting the Code Apps roadmap into what you can actually use today and what is still just announced.
The Build announcement got delayed, so the Microsoft team used the community call to show direction rather than hand you features for today. I’m also making it clear to distinct that through this whole post. About half of what follows you can use as of today. The rest you cannot yet, and the team was clear about which is which.
Preview-stage features move fast, so re-verify any Code Apps roadmap item against Microsoft Learn before you rely on it.
TL;DR
- Latest features shipped (client library v1.1.9): mobile play (online only), and OAuth/SSO connection creation from the CLI.
- June: create any data connection from the CLI; the npm CLI reaches General Availability.
- ~July, Preview: a git repo for every app (which unlocks round-trip editing between Vibe and VS Code), and server-side logic on the Managed Host.
What’s new now
Two items from the Code Apps roadmap went live this week, both riding on Power Apps client library v1.1.9.
Mobile play (online only)
You can run a code app from the Power Apps mobile app. The catch sits in one word: online. Offline play is not enabled yet, so the app needs a live connection every time it runs. There is no local cache to fall back on, so you design for the network. Handle dropped connections gracefully, and do not assume data is on the device when it goes offline.
Create connections from the CLI
You can create OAuth/SSO connections straight from the CLI. No more opening the maker portal to click through a new connection and copy a GUID back into your IDE. The plugin and agent skills were updated too, so a coding agent can create connections for you.
Worth noting: the Connect your code app to data Learn Documentation still says you can only use existing connections, not create new ones from the CLI. Might be outdated… Since it’s been demonstrated.
The quieter two were already live before this week: native Dataverse Actions & Functions (try the shared_commondataservicesforapps connector for FetchXML and expand operations), and invoking cloud flows from your app.
The Code Apps roadmap at a glance
The Code Apps roadmap slide listed eight capabilities with ETAs. Here it is, tagged by status. The team flagged everything past row four as foreshadowing.
| # | Capability | Status |
|---|---|---|
| 1 | Advanced Dataverse operations (Actions & Functions) | Now |
| 2 | Invoke cloud flows from your app | Now |
| 3 | Mobile support (online) | Now |
| 4 | Create OAuth/SSO connections from the CLI | Now |
| 5 | Create any data connection from the CLI | June |
| 6 | npm CLI reaches General Availability | June |
| 7 | A git repo for every code-first app | ~July (Preview) |
| 8 | Server-side logic on the Managed Host | ~July (Preview) |
Rows 5 and 6 were spoken as “the next couple of weeks.” Creating any connection comes shortly after the OAuth/SSO one, because some connectors need extra input collected from the user at create time. The npm CLI goes GA after more internal testing and doc updates. For now, it runs in public preview.
A note on the CLI verbs. The ones Microsoft has shown, like list-data-sources and create-connection, are illustrative rather than guaranteed syntax. They point at the direction the CLI is heading, not the final commands. The documented commands today are init, run, push, and find-dataverse-api, so check the npm CLI quickstart for what actually ships.
Rows 7 and 8 are the ones I’d watch. They change the shape of Code Apps, not just the feature list.
The two main preview bets
These two preview bets are the part of the Code Apps roadmap I keep circling back to. Both are a month or two out from now, and both change the shape of a Code App rather than adding a feature.
A git repo for every app
Today you code locally and upload a compiled artifact. Plenty of teams already push that code to a git repo by hand, on GitHub or Azure DevOps. This feature flips the relationship. Create an app from the template and it comes wired to a platform-managed git remote, with no manual setup. You push with the git commands you already know, and the platform builds and hosts straight from the repo. The new part is not git itself. It is that the platform owns the remote and the build, which is what unlocks code scanning, tests, and round-trip editing. The limitation for now: the remote is platform-managed. You do not control where it lives or its branch and access rules, and it is not your own GitHub account yet. That is exactly why bring-your-own-repo sits on the Code Apps roadmap below.
A repo per app buys three things. First, the platform can run security code scanning for teams that want it. Second, it can run tests. Third, it enables round-trip editing, which just means editing the same app from both Vibe and VS Code off one repo. An app built in Vibe (the Power Apps vibe-coding web experience) can be pulled into VS Code, edited, and pushed back. That round-trip is the part I’d watch most, because it collapses the wall between the low-code web canvas and the code-first IDE that I have spent years talking DevOps teams across.
In the future, this will grow to support repos in your own GitHub account (mirror the platform repo, then keep pushing in yours) and bring-your-own-build with your own CI/CD pipeline. It lands as a preview capability, with no firm date. Re-verify before you plan around it.
Server-side logic on the Managed Host
Code apps run entirely client-side today. The Managed Host roadmap adds a middle tier: server-side TypeScript that runs in the sandbox, not in the browser.
Logic that should not live in a client moves off the client. You get better security and room for more complex logic. The first release gives you functions your app can invoke. The middle tier respects the same data policies as the client (DLP, ACP, the allow-list for arbitrary endpoints), so it does not become a governance hole. The team floated a later headless mode for code-first workflows, but framed it as direction, not a commitment.
Someone asked the obvious question, and honestly I have asked it too: why build a middle tier when Dataverse already runs server-side logic? Here is how I read it. Dataverse server-side logic means C# plugins and custom APIs, written in C# and registered in Dataverse. For someone building a Code App in TypeScript, reaching for that means switching language, tooling, and mental model just to add a bit of server logic. A Code Apps middle tier lets you write the server side in the same language and repo as your front end. One stack, not two. So it is not that Dataverse cannot do this. The bet is on full-stack TypeScript, Node and Next.js, where most modern web work and most coding agents already live. Both can be true: Dataverse stays the right call for C# shops, and the middle tier meets TypeScript teams where they are.
The team caveated this one hard: “preview, preview, preview.” Early, and it will move before it settles.
… vs. Rayfin/Fabrics announcement
Where Code Apps fits
- Code Apps (Power Platform) vs Rayfin (and Fabric). This came up because Microsoft had just announced Rayfin: a “Backend-as-a-Service for the agentic era”, built on Microsoft Fabric. You define data models with TypeScript decorators, and it provisions the database, auth, APIs, storage, and hosting. Someone asked how Code Apps positions against it, and the exchange was exploratory, not an announcement. At first glance a coding agent can spin up an app on Rayfin that looks a lot like a Code App. The difference is underneath. Rayfin and Fabric are strong on data and data governance. What they do not bring is Power Platform’s connectors or its app-layer controls: sharing limits, conditional access, environment-group policies. The conversation pointed toward a better-together story rather than a head-to-head one, and the real open question is whether two Microsoft businesses can package it without piling on licensing complexity (should the app your organization build rely on Fabric licensing or Power Platform licensing)… Your choice.
Leave a Reply