Answered

Code apps as API server behind Power Pages? licencing costs?

(1) Share

Report

Posted on by JBC777

Not sure where to post this but i have chosen Power Pages becuase that's where the converstation starts. I have a power pages site and like many people i have well over 100 power automate functions doing backend work for the site and i am plannign to move some of the more complex power automate flows over to Azure functions. Power Automate is a great tool but its slow to develop and maintain large complex flows.

I have a few Azure functions up and running, then came along Code Apps and in theory i could create backend service functionality in Code apps, and since its included in a solution, its a bit neater for deployment than Auzre Functions.

But as always with power platform, never forget licencing! The user context isn't passed from Power Pages to Power Automate and this means in my world there is effectively 1 user 'initiating' all PA flows and i pay for compute. I don't think this is the same with Code Apps? i think the context would be passed, and thus the licence would be per user? I think the licencing for Code Apps means that Azure functions are still the way to go for backend service functionality?

Categories:

Customize & extend

General topics

I have the same question (0)

All responses (5)

Answers (3)

Sort by

Verified answer

oliver.rodrigues 9,482 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi there, lots to discuss here

- Power Pages are meant for external users, typically users would sign in using b2c identities (Entra External ID for example) or other Open ID based protocols

- licensing on Power Pages is usually license packs (100 pack authenticated users / etc)

- you can also use Power Pages for internal users using Entra ID as authentication + your regular Power Apps licenses (no issues on this)

- Code Apps are internal users only, and users need to sign in using Entra ID as it's SSO

- Code Apps are not a backend services engine - it is basically an app that users will interact with, think of it as the new Canvas Apps

Power Automate x Azure Functions x Dataverse Plug-ins

- if your flows are triggered by a Dataverse event, I would consider moving the more complex ones to Dataverse plug-ins, you write them in c# and have access to the state of the record pre/post the changes, you can make them sync or async, there are lots you can do with plug-ins.. they are also solution aware so you are able to deploy them easily enough

- if they are triggered via Power Pages js, I would consider moving them to the new server-logic, they happen server side, you code using JS, they also respect Table Permissions

- Azure Functions are great, but as you know yourself, they are outside the power platform, so you would have to deploy them separately, they are still great additional components, but if what you needs is within Dataverse, I would consider the options above

Please let me know if you need any more info

Was this reply helpful? Yes No
Verified answer

MS.Ragavendar 7,222 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!
@JBC777,

From an architecture standpoint, you’re trying to solve two separate concerns. How to structure backend logic cleanly, and how licensing is impacted by where that logic runs.

Power Pages is designed for external-facing scenarios where user identity typically comes from Entra External ID (B2C) or other identity providers. In that model, users don’t carry a traditional Power Platform license, and backend processing (like Power Automate flows) usually runs under a service context. This is why, in your current setup, flows effectively behave as if a single “system user” is executing them and you’re primarily paying for execution rather than per-user licensing.

Code Apps, however, are not a backend service layer. They are an app model similar to Canvas Apps, intended for internal users authenticated via Entra ID. The user context is central there because the app is user-driven. Even though solutions make deployment neater, Code Apps don’t replace backend processing engines and are not designed to host reusable service logic in the same way. So they don’t solve your problem of replacing complex backend flows.

Have you worked on SharePoint Framework development earlier, If yes this is more similar to that.

Code Apps is nothing but instead of Power Fx language this allows to build applications based on react based applications and then run and host them seamlessly within the Microsoft Power Platform.

When you look at backend logic specifically, there are three realistic options inside and outside the Power Platform:

If your flows are triggered by Dataverse events, Dataverse plug-ins are the most native and scalable option. They execute close to the data, give you access to pre/post state, support both synchronous and asynchronous execution, and are fully solution-aware, which makes ALM significantly cleaner than maintaining large flows.

If the logic originates from Power Pages interactions (for example via JavaScript or form submission), the newer server-side logic capabilities in Power Pages are worth considering. They keep execution inside the platform boundary, respect table permissions automatically, and remove the need to orchestrate Power Automate for every interaction.

Azure Functions remain the most appropriate choice when you need true backend service capabilities: complex processing, external integrations, performance-critical logic, or reusable APIs. They also give you full control over scaling and avoid the overhead and design limitations of large Power Automate flows. The trade-off, as you’ve already identified, is that they sit outside the Power Platform and require separate deployment and lifecycle management.

From a licensing perspective,

Azure Functions continue to be the cleaner option for backend services. They decouple execution from Power Platform licensing models and avoid the ambiguity of user context that you see with Power Pages triggering flows.

Code Apps don’t change that equation because they are not designed to execute backend workloads.

You need to enable the code apps & End users that run code apps need a Power Apps Premium license.

For More Information kindly refer Power Apps code apps documentation

In summary, moving complex flows to Azure Functions still makes the most architectural and licensing sense for backend services. If the logic is tightly coupled to Dataverse, plug-ins are even better.

Final Verdict : Code Apps should be viewed as a UI layer evolution, not a replacement for backend processing.

Was this reply helpful? Yes No
Suggested answer

Valantis 5,977 on at

Like (1)

Report
Copy link

Link copied!

Hi @JBC777,

Your instinct is correct. Microsoft docs confirm: end users that run Code Apps need a Power Apps Premium license. So if Code Apps serve as your backend API layer for Power Pages, every user hitting those endpoints needs a Premium license. That's a significant cost at scale.

Azure Functions remain the better choice for backend service functionality behind Power Pages. You pay for compute only, no per-user licensing, and you get full control over the runtime. The solution packaging advantage of Code Apps doesn't outweigh the licensing cost for this use case.

Ref: https://learn.microsoft.com/en-us/power-apps/developer/code-apps/overview

Best regards,

Valantis

✅ If this helped solve your issue, please Accept as Solution so others can find it quickly.

❤️ If it didn’t fully solve it but was still useful, please click “Yes” on “Was this reply helpful?” or leave a Like :).

🏷️ For follow-ups @Valantis.

📝 https://valantisond365.com/

💼 LinkedIn

▶️ YouTube

Was this reply helpful? Yes No
Verified answer

11manish 2,633 on at

Like (0)

Report
Copy link

Link copied!
I would continue using:

Power Automate for orchestration and low-complexity workflows.

Azure Functions for backend services and business logic.

Unless there is a very specific capability in Code Apps that you need, Azure Functions remain the more proven and scalable approach for backend service

functionality.

The licensing model is only one factor, but from an architecture, maintainability, performance, and enterprise governance perspective, Azure Functions are still the

safer choice for complex backend processing behind Power Pages.

Was this reply helpful? Yes No
Suggested answer

Fubar 8,501 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!

Just to add to what others have already posted. FYI: Dataverse operations performed using Dataverse Workflows & Plugins are treated as internal API calls and do not count towards API limit counters, vs Power Automate Flow each operation node is an API call that does count towards API limit counters.

At the end of the day, the key is using the most appropriate method for what you need to achieve.

Was this reply helpful? Yes No