For years, Microsoft partners building portals on Power Pages have lived with the same trade-off. Anything that needed to stay secret — API keys, business rules, validation logic — had to be pushed out to Azure Functions or Power Automate flows. Anything sensitive that lived in client-side JavaScript was, by definition, visible to anyone with browser dev tools.
That changed on April 1, 2026, when Microsoft moved Power Pages server logic to General Availability. Server logic lets developers run JavaScript directly on the Power Pages server — secure, governed, and natively integrated with Dataverse. For partners delivering enterprise portals, this isn’t a minor feature release. It’s a structural shift in how Power Pages projects should be architected from day one.
This guide covers what Power Pages server logic is, why it matters for partners, when to use it (and when not to), and how it changes the way MTC delivers portals in 2026.
What Is Power Pages Server Logic?
Power Pages server logic is server-side JavaScript that runs inside the Power Pages runtime itself. You write the code in the Power Pages design studio or Visual Studio Code, store it in Dataverse, and call it via a clean REST endpoint from your client pages.
The code follows the ECMAScript 2023 standard, runs on Microsoft’s servers (not the browser), and is protected by web roles and table permissions. There’s no separate hosting to provision, no Azure Function App to maintain, and no custom authentication code to write — the application session handles auth and CSRF token validation automatically.
How It Works
A typical server logic implementation has three parts:
- The function — written in JavaScript, mapped to a standard HTTP method (
get(),post(),put(),patch(),del()) - The endpoint — auto-generated at
https://<site-url>/_api/serverlogics/<server-logic-name> - The client call — standard fetch from your Power Pages page, with a CSRF token included
That’s it. No middleware, no separate deployment pipeline, no Azure resource group to manage.
Why Server Logic Matters for Microsoft Partners
Most partners delivering Power Pages portals today are running one of three architectures: client-side JavaScript for everything (insecure), Power Automate flows for backend logic (slow and licensed per call), or Azure Functions sitting between Power Pages and the data (powerful but architecturally heavy). Server logic collapses the second and third pattern into the platform itself.
Here’s what changes for partner delivery teams.
1. Sensitive Logic Stays Off the Browser
Before server logic, any code that called an external API from Power Pages either ran in the browser (exposing keys and endpoints) or required a custom Azure Function. Now the partner can move payment verification, inventory checks, discount calculations, or any third-party API call directly into the platform — without ever exposing credentials in the network tab.
2. Faster Portal Delivery
A typical enterprise Power Pages build used to need three platforms working together: Power Pages for the UI, Power Automate for orchestration, and Azure Functions for anything that needed real code. Each added cost, latency, and complexity. With server logic, much of that work consolidates back into Power Pages — fewer moving parts, faster delivery, lower long-term maintenance burden.
3. No More Power Automate Flows Just to Hit an External API
This is the change partner delivery teams will feel most immediately. Before server logic, the standard pattern to call any external data source from Power Pages was: client JavaScript → Power Automate flow → external API → back through the flow → back to the page. Every external call cost a flow run, added latency, and meant licensing implications at scale.
A simple example: a Power Pages SPA showing live currency exchange rates. The old pattern was a Power Automate flow triggered by the client, hitting the exchange rate API, and returning the response. Functional, but slow and licensed per call. With server logic, the page calls a server logic endpoint directly, the endpoint hits the exchange rate API server-side with the credentials hidden, and the response comes back in a single round trip. No flow run, no licensing overhead, faster response, cleaner architecture.
Multiply that pattern across every external integration in a typical enterprise portal — payment APIs, address lookups, third-party CRM calls, inventory checks — and the architecture simplifies dramatically.
4. Native Dataverse Integration
Server logic runs inside the Power Pages stack, so it talks to Dataverse natively. Querying, updating, and deleting records happens through built-in server objects, with web roles and table permissions enforced automatically. There’s no custom authentication wrapper, no service principal to configure for the simple cases, and no separate ALM pipeline for the backend code — it ships with the rest of your Power Pages solution.
5. Enterprise-Grade Governance
The General Availability release in April 2026 added two enterprise capabilities that matter at the partner level. Unbound Dataverse custom APIs can now be called directly from server logic, which means reusable business logic defined once in Dataverse can be invoked from portals without duplication. And tenant administrators can disable external HTTP calls site-by-site, giving compliance teams a network boundary control that didn’t exist before.
When to Use Server Logic (and When Not To)
Server logic is the right answer for a lot of portal scenarios, but it isn’t a replacement for everything. Here’s how MTC’s delivery team makes the call.
Use Server Logic When You Need To
- Call an external REST API with secret credentials (payment gateways, third-party CRMs, custom backends)
- Perform server-side validation on form submissions
- Run business rules that must not be visible to end users
- Transform or filter data before returning it to the client
- Implement secure CRUD against Dataverse with consistent permissions
Don’t Use Server Logic When You Need To
- Run long-running background jobs (240-second timeout cap)
- Use browser-specific APIs (
fetch,XMLHttpRequest, DOM access — none are available server-side) - Process large file uploads or run heavy compute (Azure Functions still wins here)
- Trigger logic on a schedule (use Power Automate or Azure for scheduled jobs)
- Use Node.js libraries (server logic is pure ECMAScript 2023, no
npmecosystem)
A Realistic Hybrid Architecture
In most enterprise portal builds, the right answer in 2026 is a hybrid. Use Power Pages server logic for the secure middle layer — anything that needs to call an API, validate input, or apply business rules. Keep Azure Functions for compute-heavy or long-running work. Keep Power Automate for scheduled or event-driven orchestration that doesn’t need to be in the request/response path. Use Liquid and client JS only for UI behaviour. That split is faster to build, cheaper to run, and easier to govern than the old three-platform pattern.
Configuring Server Logic for Production
A few governance settings every partner should configure on day one:
| Site Setting | What It Does | MTC Recommendation |
|---|---|---|
ServerLogic/Enabled | Enable / disable the feature | true |
ServerLogic/AllowedDomains | Restrict which external domains can be called | Set explicit allow-list in production |
ServerLogic/TimeoutInSeconds | Maximum execution time | 120 default, 240 max |
ServerLogic/AllowNetworkingToAllDomains | Allow networking across all domains | False in production |
Setting AllowedDomains is the single most important configuration step. It prevents a developer from accidentally introducing a call to an unapproved endpoint and gives the tenant administrator a clear list of approved integrations for review.
How MTC Delivers Power Pages Server Logic for Partners
MTC has been building on the Power Pages stack since the Adxstudio days, and our delivery model is built specifically for Microsoft implementation partners who need a development-first portal team. Server logic fits naturally into that delivery — we use it across our 25+ AppSource add-ons and on partner engagements where security, performance, and clean architecture matter.
A typical server logic engagement covers:
- Architecture review — deciding where server logic fits versus Power Automate, Azure Functions, or client JS
- Implementation — server logic functions, Dataverse integration, external API calls, CSRF handling
- Governance setup — allowed domains, timeout configuration, web role and permission mapping
- ALM — deployment pipelines, environment promotion, version control via Visual Studio Code
We work as a Power Pages portal partner behind the scenes for Microsoft CSPs, ISVs, and boutique consultancies — your client never sees us, and you keep the relationship.
Frequently Asked Questions
We held off on server logic because it was in preview. Is it safe to ship in production now?
Yes. Since General Availability, we’ve started using server logic in new Power Pages engagements where secure API integrations or server-side validation are required. In our experience, it removes a significant amount of Azure Function and Power Automate complexity without sacrificing governance. We still review each solution architecture individually, but for standard portal integrations, server logic is now a production-ready option that we actively recommend and deploy.
When should we still use Power Automate flows instead of server logic?
We use server logic for synchronous request/response scenarios where the portal needs an immediate answer, such as validating customer data, calculating pricing, or calling an external API during a user session. We still use Power Automate for asynchronous processes such as approval workflows, scheduled reminders, document generation, and background integrations. On a recent partner project, server logic handled real-time validation while Power Automate managed the approval and notification process after submission.
Does server logic work with the new Power Pages SPA and pro-code development model?
Yes. Server logic exposes standard REST endpoints, so it can be called from React, Angular, Vue, or vanilla JavaScript in exactly the same way. We’ve used this approach in modern portal projects where React handled the user experience while server logic managed secure API calls and Dataverse operations behind the scenes. The result is a cleaner architecture that keeps sensitive business logic on the server while allowing complete flexibility in the frontend framework.
Conclusion
Power Pages server logic is the most significant architectural shift in the platform since the Power Apps Portals rename. For Microsoft partners delivering enterprise portals, it removes a major reason to bolt Azure Functions onto every project and gives compliance teams a cleaner, more governed integration story.
If you’re a Microsoft partner planning a Power Pages build in 2026 — new project, migration from Power Apps Portals, or modernisation of an existing site — server logic should be in the architecture conversation from day one.
We’ve used server logic on portal builds across our 25+ AppSource add-ons and on partner engagements where security and clean architecture mattered. In a follow-up post, we walk through a real example — calling an external REST API securely from a Power Pages site, with full code, screenshots, and the gotchas we hit along the way. Read the server logic walkthrough →
Need a development-first Power Pages partner for your next engagement? Talk to MTC’s Power Pages team — 80+ Microsoft consultants in Hyderabad, 25+ AppSource add-ons live, white-label delivery for partners worldwide.
