Halilcan Soran

Tag: Power Pages

  • Power Pages Agentic Code Just Got Server-Side Skills and I Cannot Wait to Try Them

    Power Pages Agentic Code Just Got Server-Side Skills and I Cannot Wait to Try Them

    Power Pages agentic code server-side skills generating Liquid and Web API logic

    Microsoft just shipped three new skills for the Power Pages agentic code plugin that finally let GitHub Copilot and Claude Code CLI generate server-side logic, not just front-end markup. The announcement landed on the Power Platform blog and this is the gap-closer I have been waiting for. Power pages agentic code server-side generation is the part that was missing.

    If you have built anything non-trivial on Power Pages you know the pattern. The studio handles the front-end fine. The moment you need a Web API call, a table permission rule, or a Liquid template that actually does work, you are out of the visual layer and into code that the AI tools could not see properly.

    What it actually does

    The plugin now ships three new skills focused on the server-side surface of a Power Pages site. From the post and what I have read so far, these cover generating and wiring up Liquid templates with the right context, scaffolding Web API calls against your actual Dataverse tables, and producing the configuration around table permissions and site settings that normally requires you to know exactly which knob to turn.

    The important detail is grounding. The plugin pulls from your real site context: the tables you have, the columns on them, the page structure, the site settings already in place. So when GitHub Copilot or Claude Code CLI generate Liquid or a Web API snippet, it is generated against your actual environment, not a hypothetical portal.

    I wrote about this grounding problem before in an earlier post on Power Pages and AI. Generic LLM output for Liquid looks correct and breaks immediately on deploy because the model has no idea what your tables are called or what permissions are wired up. Environmental grounding is the entire game here.

    Why server-side AI generation is different leverage

    Front-end scaffolding from AI is useful but cheap. Anyone can prompt a model to spit out HTML and CSS for a form. The hard part of Power Pages was never the markup. It was the layer underneath: Liquid templates, Web API permissions, plugin logic, the settings that decide whether a record is visible to an authenticated contact or not.

    That layer is where sites break. That layer is where you used to bolt on a Power Automate flow because it felt easier than figuring out the right server-side pattern. And bolting on a flow for what should be a server-side query is exactly the kind of decision that creates a silo three months later when nobody remembers why the form posts to a flow instead of using the Web API directly. Understanding Power Automate error handling patterns helps when those flows do need to exist, but the goal should be keeping server-side work on the server side.

    Generating server-side logic with proper grounding cuts that path off. You stay inside the site. You use the layer that was already designed for it. The trade-off is real though: you now have AI-generated Liquid and permissions in a place where mistakes are harder to spot than a broken button. Server-side bugs do not show up as the dreaded broken image icon. They show up as a record being visible to the wrong user, which is a much worse failure mode.

    This is why I keep saying tool design for AI agents is an API design problem. The quality of the environmental signals fed to the model matters more than the model itself. Microsoft Learn for Power Pages is the reference I keep open when I am sanity-checking what these skills produce.

    What I would do with it this week

    I would pick a small internal-style site with two or three Dataverse tables, authenticated users, and one workflow that currently lives in a Power Automate flow it should not live in. Something where a list view filters by the logged-in contact, and a form writes back to a related table.

    Then I would have Claude Code CLI do three things. First, generate the Liquid for the filtered list using the new skill, against the real tables. Second, generate the Web API call for the form submission with the right permissions, instead of the Power Automate detour. Third, write a small piece of logic that should obviously fail without context, like referencing a column that does not exist, just to see how the grounding holds up.

    The point is not to ship anything. The point is to find where it breaks. In my experience, the only honest way to evaluate one of these releases is to push it until it produces something wrong, then look at why. If you are thinking about where this fits in a broader agentic architecture, most agentic workflows are just fancy if/then logic until the grounding is solid enough to trust the generated output in production.

    If the grounding is as good as the announcement suggests, this changes how I would start any new Power Pages build going forward.

    This post was inspired by Build your server-side logic with AI: new Power Pages Agentic Code skills via Microsoft Power Platform Blog.

  • Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages Just Got Server-Side Logic You Can Actually Generate With AI

    Power Pages server side logic AI code generation with GitHub Copilot and Claude Code CLI

    Power Pages server-side logic has always been where the low-code promise quietly falls apart. You get a clean design studio, drag-and-drop layouts, reasonable out-of-the-box forms. Then someone asks for server-side validation that cannot safely run in the browser, a secure external API call where the key can never touch the client, or a multi-table transaction that needs to complete before a Dataverse record is committed. And these three new skills are for modern single-page application (SPA) Power Pages sites specifically — not the classic Liquid-templated architecture — which matters if your audience spans both worlds. And suddenly you’re either writing it from scratch by hand, spending an afternoon in documentation, or handing it off to someone on a proper dev team and waiting. I came across a post from the Microsoft Power Platform Blog about three new agentic code skills for the Power Pages plugin, and it hit on something I’ve been thinking about for a while: the ceiling for what a single automation developer can ship in Power Pages without a dedicated dev team behind them just moved.

    What Server-Side Logic in Power Pages Actually Means and Why It Was Always the Hard Part

    Power Pages is a low/no-code portal builder sitting on top of Dataverse. The studio handles most of the front-end work reasonably well. But portals have always had a split personality. There’s what you can configure visually, and then there’s the layer underneath. For modern SPA-style Power Pages sites, that means server-side JavaScript endpoints that handle validation, secrets, and external API calls; Cloud Flow connections for backend automation; and integrations with systems that can’t be wired directly from the browser. That second layer is not configuration. It is code. And it requires context about your specific environment to write correctly.

    This is why generic AI code generation has never worked well here. Asking an LLM to write you a server-side endpoint without knowing your Dataverse schema, your table structure, or your page context produces something that compiles and fails as soon as you wire it to real data. The model doesn’t know your environment. You end up doing the real work yourself anyway, just with a plausible-looking starting point that may or may not match reality.

    What These Agentic Code Skills Actually Do When You Run Them

    The specific thing that matters here is scope. These are not general-purpose code suggestions. The plugin is grounded in your actual Power Pages site. It understands your tables, your site settings, your page context — because architect agents analyze your actual code and query your Dataverse environment before generating anything. Then they propose specific changes for your review before anything is applied. That propose-then-approve loop is not a limitation; it is a selling point. You stay in control of what lands in your site. When you describe the server-side behaviour you need, the generated code is scoped to your environment, not a hypothetical portal that shares no properties with yours.

    That is the distinction most people will miss when they skim the announcement. The three new skills are /add-server-logic, which generates server-side JavaScript endpoints for validation, secrets management, and cross-entity operations; /add-cloud-flow, for connecting backend automation; and /integrate-backend, for wiring in external systems. These join six existing skills in the plugin — nine total. Each one is pulling from what the plugin already knows about your site structure. The output is contextually aware in the same way that Claude operating with good tool design returns useful results because it has real signals to work with, not because the model is smarter in isolation. I wrote about this in the context of agentic workflows generally: tool design is an API design problem, and what makes these skills interesting is that Microsoft has done that tool design work to give the model actual environmental context to reason against. If you want to go deeper on how Claude functions as that reasoning layer in enterprise contexts, Claude as an Orchestration Brain Is the Most Interesting Thing Happening in Enterprise AI Right Now covers the architecture side of that in more detail.

    The Claude Code CLI path is worth calling out specifically. If you’re already working with Claude for orchestration or code tasks outside the Power Platform, having it also handle your Power Pages server-side work inside the same workflow is practically useful. You’re not switching contexts or tools.

    The Specific Scenario Where I Would Use This First

    The scenario I keep running into internally is validation logic that cannot run client-side — business rules that reference data from other tables, check against external state, or need to complete before a Dataverse write is committed. That is exactly the /add-server-logic case: a server-side JavaScript endpoint that runs the check first, keeps any secrets out of the browser, and returns a clean result to the form. Describing that condition and getting generated code that already references your actual table names and schema cuts the build time significantly. That’s the first thing I’d point this at.

    The second would be secure external API calls where credentials cannot touch the browser at all. You describe the integration — what the endpoint expects, what you need back — and /add-server-logic generates an endpoint that already references your actual environment. That is a different kind of useful than autocomplete, and it removes a class of security mistake that comes from passing keys through the client.

    Where This Still Has Limits and What You Still Need to Know Yourself

    I want to be direct about this because I’ve seen the same pattern play out with AI-assisted flow building in Power Automate: faster to working and closer to production are not the same thing. Generated server-side code that looks correct can still have permission boundary issues, silent failures on edge case inputs, or endpoint logic that works on the happy path and throws an unhandled error when a value comes back null from Dataverse. The model generates against your environment, but it does not run your QA process.

    You still need to understand how Power Pages table permissions actually interact with Web API calls. You still need to know what a plugin execution context looks like and where it can fail. If you’re purely vibe building with generated code and no mental model of what’s running underneath, you’ll ship something that passes your own demo and fails on the first real user submission. This is the same problem that comes up when adding Copilot to a Power App gets treated as a shortcut around understanding what’s actually running under the surface. The same principle I keep coming back to on my own work applies here: the AI is the generation layer, you are still the verification layer.

    That said, for an automation developer who already understands the Power Pages architecture and just needs to move faster on the server-side code parts, this is genuinely useful. The ceiling for what one person can build without a dedicated dev team behind them has moved. I’ll be testing this on the next portal build that needs real server-side work, and I’m curious how much of the scaffolding holds up in practice.

    Frequently Asked Questions

    How do I generate server-side logic for Power Pages using AI?

    You can use the three new agentic code skills available through the Power Pages plugin, which work with tools like GitHub Copilot or Claude Code CLI. Unlike generic AI tools, these skills are grounded in your actual site environment, so the generated server-side endpoints, Cloud Flow connections, and backend integrations are written against your specific Dataverse schema and site structure rather than a generic example. Note that these three skills are designed for modern SPA-style Power Pages sites, not classic Liquid-based portals.

    What is the difference between Power Pages server-side logic and front-end configuration?

    Front-end configuration in Power Pages covers layouts, forms, and visual design handled through the studio. For modern SPA-style Power Pages, server-side logic refers to the layer underneath the client: JavaScript endpoints for validation and external calls, Cloud Flow integrations for backend automation, and connections to external systems. This layer is not configuration — it is code that requires environment-specific context to write correctly. This second layer requires actual coding knowledge and environment-specific context to get right.

    Do these Power Pages agentic code skills work with classic Liquid-based sites?

    No. The three new skills — /add-server-logic, /add-cloud-flow, and /integrate-backend — are designed for modern single-page application (SPA) Power Pages sites, not classic Liquid-templated portals. If your Power Pages work is primarily in the classic architecture, these skills do not apply to your current stack.

    When should I use AI-generated plugin logic in Power Pages instead of writing it manually?

    AI-generated plugin scaffolding is most useful when you need to enforce business rules on record creation or updates and want a working starting point built around your actual Dataverse tables. It reduces the time spent in documentation and removes the dependency on a dedicated development team for straightforward but environment-specific server-side requirements.

    This post was inspired by Build your server-side logic with AI: new Power Pages Agentic Code skills via Microsoft Power Platform Blog.