Power Apps and Azure: The Hybrid Architecture Boundary

Power Apps, Dataverse, Azure, and custom APIs: the enterprise architecture boundary in one hybrid solution.

The decision to combine platforms has already been made in the rooms this guide is written for. A Power Apps front end sits on Dataverse, an order system or an ERP holds the records that matter, and somebody has proposed an Azure Function or a custom .NET API to carry the logic the low-code layer strains under. The enterprise architect, the application development manager, and the Power Platform owner now share one solution and no map of it. This guide is the map: how to combine Power Platform and .NET components in one solution without duplicated logic, unclear data ownership, or an integration nobody will admit to owning.

What This Guide Owns, and What It Hands Off

This guide owns the interior of one hybrid solution: what Power Apps and Dataverse should hold, when Azure services and custom code take over, and how identity crosses the layers. It also owns how source-of-truth rules are set between Dataverse and the systems of record, and what lifecycle each layer runs on.

The choice between the platforms is a different question. Whether to build in Power Apps at all, or in custom .NET instead, is run end to end in Power Apps vs. Custom .NET: Decision Guide; this guide assumes that decision returned “both.” Whether Dataverse or SQL Server should hold a given workload is argued in Microsoft Dataverse vs SQL Server, including its case for a hybrid data strategy. Whether Power Apps should be ruled out for a workload is a disqualifier question this guide does not run. Conditional access and application consent policy are identity-layer decisions, left to that layer.

Why a Hybrid Solution Needs a Written Boundary

The question that decides whether the estate stays governable is the one buyers ask in exactly these words: where does the app end and the platform begin? Answered informally, it is re-answered by each developer, maker, and contractor, differently each time. The resulting hybrid architecture is not designed; it accretes.

Integration debt is the running total of undocumented point-to-point connections a solution accumulates while nobody draws that line. A canvas app calls a stored procedure directly here, a flow patches an ERP field there, a scheduled job copies a table nightly because a demo needed it. Three years later a schema change breaks four consumers, and the discovery work costs more than the original build.

The expensive failure is usually not technical. A delegation miss or a throttled call is findable with the platform’s own diagnostics once someone looks. What stays broken is ownership. Business rules implemented twice, once in Power Fx and once in C#, drift apart; two stores are each believed to be authoritative for the same customer record; a custom service runs in production with no team on its incidents. A boundary document prevents this at the price of a page of writing per layer.

A hybrid program survives its second year on one written record: who owns which layer, and what each owner is on the hook to produce. The rest of this guide is that record’s template.

The Five-Layer Boundary Framework

Five layers carry the solution. The framework asks three questions of each layer: what does it own, who owns it, and what written artifact proves both.

Layer	What it owns	Who owns it	The artifact that proves it
Experience	Screens, tasks, approvals, and the workflow users touch, in Power Apps and Power Automate	A business-side product owner, named	A screen-and-flow inventory naming each maker-built asset and its business purpose
Data	Dataverse tables, the enterprise stores behind them, and the ruling on which store wins	A data owner per business entity, named	The source-of-truth register: entity, authoritative store, sync direction, conflict rule
Services	Reusable business rules, calculations, and integrations in Dataverse plug-ins, custom APIs, and Azure services	An engineering lead, named	An API contract per service: consumers, versioning rule, error behavior
Integration	The connections between layers and to outside systems: connectors, events, queues	The integration or platform team, named	A connection inventory: each integration, its trigger, its volume class, its monitor, and the identity the connection runs as
Operations	Release, monitoring, incidents, and support across the other four	A service owner accountable for the whole solution, named	A runbook naming the release path and the incident owner per layer

Every cell in the last column is producible in days rather than quarters, because the bar is honesty, not completeness: an inventory with explicit unknowns and a named owner accepting the gap counts; a claim that the solution is fully documented does not.

What Power Apps and Dataverse Should Own

What should Power Apps own in a hybrid architecture? The work that changes at the speed of the business: screens, task flows, approvals, and the data capture that feeds them. This is where low-code earns its keep, because a business-facing form that changes monthly should not need a code deployment. Dataverse should own the application’s working data: the records the app creates, the state its processes carry, and the security model those records inherit from the platform.

The boundary test is fitness under load, and Microsoft documents where that fitness ends. Where a query operation cannot be delegated to the data source, Power Apps retrieves the first 500 records by default, a limit that can be raised to 2,000. The page states the limit exists to keep the app performing well; the specifics are on Query limitations: Delegation and query limits. A workload whose correctness depends on scanning beyond that window has crossed the boundary, whatever the screen looks like.

Logic obeys the same discipline. A rule that exists to serve one app belongs in the app. A rule that two consumers apply, or that auditors trace, or that survives the app’s replacement, is enterprise logic wearing app clothing, and it belongs in the services layer. The tell is the second consumer: the day another app, another flow, or another team needs the same calculation, the rule has outgrown Power Fx, and copying it is how divergence starts.

When Custom APIs and Azure Services Take Over

When to use Azure services with Power Platform is answered by workload character, not by preference. Four characters move work across the line: logic more than one consumer applies, volume beyond the platform’s documented service limits, processing that runs long or asynchronously, and integrations that carry contractual or regulatory weight.

The platform documents its own edge. Dataverse enforces service protection API limits, evaluated over five-minute periods, documented on Service protection API limits. That page states a client can expect to exceed the number-of-requests and execution-time limits for a five-minute period before the limits take effect, with concurrent requests behaving differently. An integration designed to hammer Dataverse as a message bus is designed against the platform’s documented posture; high-volume system-to-system movement belongs below the boundary, on infrastructure priced and scaled for it.

The component classes are few and the design questions matter more than the products. Logic that stays close to Dataverse records can meet its services-layer contract inside the platform first, as Dataverse plug-ins; Azure Functions or App Service carry the logic that leaves the platform; API Management fronts a service once a second consumer calls it; Service Bus or Event Grid decouple producers from consumers where timing and volume demand it. The questions per component are the services row of the framework: who consumes it, what the contract is, how versions roll, and what happens on failure. The event-driven variant of these questions has its own treatment in Event-Driven Integration on Azure.

The seam back to the platform is documented and deliberately thin. A custom connector is a wrapper around a REST API that allows Logic Apps, Power Automate, Power Apps, or Copilot Studio to communicate with that REST or SOAP API, per the Custom connectors overview. That wrapper is the healthy shape of Power Platform custom backend design: the app consumes the governed contract other consumers get, instead of a private tunnel into the database. When a custom API exists and the environment’s data loss prevention policy closes the direct connectors beside it, makers stop reaching for credentials to the systems behind it.

Power Platform Delivery with the Guardrails Built In

i3solutions delivers Power Apps and Power Platform development, governance, and modernization for enterprises where the platform runs real business processes under real audit obligations.

Review Power Platform Services

Source-of-Truth Rules Between Dataverse and Systems of Record

A source of truth ruling names, for each business entity, the one store whose value wins when copies disagree. In a hybrid build the candidates are plural: the customer exists in the ERP, in Dataverse, and in whatever the integration cached. Without the ruling, each layer trusts its nearest copy, and reconciliation becomes a quarterly archaeology project.

The register is short and blunt: entity, authoritative store, direction of synchronization, and the conflict rule. For the entities an enterprise system already owns, the ruling is usually to leave ownership there and treat Dataverse as a working copy with a declared refresh contract. Microsoft’s platform carries a mechanism for exactly this posture. A virtual table is a custom table in Microsoft Dataverse that has columns containing data from an external data source, surfaced rather than copied, per Create and edit virtual tables that contain data from an external data source. What that mechanism does not change is the ruling itself: surfacing data is a technical choice, and ownership is a governance choice, made per entity and written down.

Identifiers are the second half of the ruling. When the ERP’s customer number, the Dataverse GUID, and the API’s key all circulate, the register says which one crosses layer boundaries and where the mapping lives. One mapping, owned by the data layer, beats four mappings owned by nobody.

Where copies exist, drift is a schedule question: a copy nobody reconciles diverges at whatever rate the business changes. The register therefore carries a reconciliation cadence and a named owner for each synchronized entity, with unknowns recorded as unknowns. Your data layer is in shape when each entity has one ruling, one mapping, and one reconciliation owner; the work is somebody else’s when the dispute is really about the platform choice itself.

 

Identity and Access Across the Boundary

The security boundary in a hybrid build is the set of identities each layer accepts and the permissions those identities carry, written per layer rather than assumed at the perimeter. Two identity postures coexist in one solution, and confusing them is the root of the ugliest hybrid incidents.

The experience layer runs on user identity. A Power App should act as the signed-in person, through connections that carry that person’s own authorization, so what the app can reach is what the user can reach. Not every connection behaves this way: a connector authenticated with a shared credential or a service principal carries that identity’s authorization rather than the signed-in person’s, and each connection’s posture is named in the connection inventory rather than assumed. Keep the user-identity default: an app that borrows a privileged shared account to widen its reach has converted a permission decision into a standing exposure.

The services and integration layers run on service identity. Between Azure components, Microsoft documents manual handling of secrets and certificates as a known source of security issues and outages. It documents managed identities as eliminating that handling for communication between Azure services that support them, per What is managed identities for Azure resources?. The design rule that follows: a personal account in a connection string, or a password in an app setting, is a boundary defect on the same footing as duplicated logic, and it goes on the same remediation list.

Write the crossing points down. Where a user-context call enters the services layer, the API decides what the user’s context entitles; where a service-context call touches business data, the data layer’s register says which entity and why. Which users get which apps, and what conditional access demands of them, are identity-layer decisions made outside this solution; the boundary document still names the access and consent assumptions each crossing depends on, so a policy change outside the solution is visible as a risk inside it. The hybrid estate’s security tooling is treated in depth in Hybrid Microsoft Integration Security.

The boundary under request load: moving the code to Azure is not moving the load

As of September 2026, an Azure Function that still writes every record back through Dataverse as an application user has moved the code and kept the load: per Microsoft’s requests limits and allocations documentation, that traffic spends a tenant-level pool Microsoft sets for non-licensed identities, a pool that Power Apps user licenses do not add to. Moving integration work into Azure moves the Power Apps and Azure boundary only when the traffic stops crossing back into Dataverse. i3solutions’ recommendation is to price each crossing before the Azure spend is approved. Whether a specific move pays is a decision for your own tenant, its licenses and its volumes.

The size of that pool depends on the tenant’s licenses. For the row Microsoft labels Power Apps (all licenses), its table of pooled non-licensed tenant-level requests per 24 hours lists 25,000 base requests with no per-license accrual for the tenant. Where the tenant also holds Dynamics 365 Enterprise or Professional licenses, the same table shows a larger pool that grows with each of those licenses.

Name the pool exactly: it is the tenant pool, not the per-user allocation. Microsoft tracks a licensed user’s capacity at an individual user or flow level, and that capacity can’t be pooled at environment or tenant level; the tenant pool is a separate allocation that only non-licensed identities draw on. Both are request allocations, counted per 24 hours, which is a different Microsoft mechanism from the delegation and service protection limits described earlier on this page.

Price each crossing before you approve the move

A proposal that says an Azure move relieves the platform is unproven until each crossing it creates names the identity it runs as, because the identity decides which allocation the crossing spends. Three crossings cover the hybrid solution this page describes.

User-context calls from the app to connectors and Dataverse run as the signed-in person and count against that person’s own allocation, not the tenant pool; where each license’s own request ceiling sits is a licensing question with its own page.

Service-context calls into Dataverse from Azure, made as an application user or another non-interactive identity, spend the tenant pool. Microsoft states that this pool can only be used by these non-licensed users and not by users with assigned interactive user licenses. Because the Power Apps row accrues nothing per license, buying more Power Apps licenses for people does not enlarge the pool an Azure service spends. Power Automate flows that run under service identities are on the same meter, and how flow identities draw on the same tenant pool is set out separately.

Calls from Azure to a system of record that never enter Power Platform sit outside both allocations on i3solutions’ reading of Microsoft’s definition, which describes requests in Microsoft Power Platform as actions that a user takes across different products. Those calls are priced and scaled on the Azure side.

Route high-volume system-to-system movement around Dataverse rather than through it as an application user, unless the tenant pool has been sized for that volume.

The record for this is the connection inventory in the framework table above, which already names the identity each connection runs as. For every crossing the Azure move creates, extend its row with three fields: the allocation it spends, its expected daily volume or an explicit unknown, and the named owner who answers when the pool runs short. In i3solutions’ discovery method those fields belong to the license entitlement and ownership questions settled at discovery, answered before the Azure move is approved, not after the first throttling incident.

Where i3solutions lands: no Azure move is approved until each crossing it creates has an inventory row naming its identity, its allocation and its owner.

When a hybrid boundary is the wrong design

“We already pay for Azure, so the logic should live there” is the objection that adds a boundary the solution does not need. Keep everything in Power Platform when no second consumer needs the data or the rule, the app’s queries stay inside the delegation window this page documents, and its traffic sits inside the users’ own allocations: adding Azure then adds an operations owner, a lifecycle and an identity crossing for no gain. If those conditions split, for example one rule gains a second consumer while the app stays inside its delegation window, move that rule alone to the services layer and keep the app where it is.

Build wholly custom on Azure when the experience layer itself is disqualified, not only the services layer; the signs the experience layer itself has outgrown Power Apps are set out on their own page. The opposite objection, “We already pay for Power Apps, so everything should run there”, fails the day a second system consumes the rule, which is this page’s second-consumer test.

Lifecycle and Operations, Layer by Layer

Each layer ships on its own lifecycle, and pretending otherwise is how releases break. Power Platform assets move through environments as solutions under the platform’s application lifecycle management model; custom services move through source control, pipelines, and release gates the engineering organization already runs. The question is not which lifecycle wins; it is how the two coordinate. The answer is a written compatibility contract: which API versions each app release requires, and which app versions each API version supports.

Three operational rules keep the contract honest. Versioning: a custom API consumed by a maker-built app changes by addition, with breaking changes shipped as a new version and retired on a date, because the platform side cannot hotfix on the API team’s schedule. Monitoring: each integration in the inventory has a monitor and a named responder, and silence is treated as an unknown rather than as health; the estate-level depth is in Microsoft Integration Monitoring and Observability for Enterprises. Support: the runbook routes each failure class to a layer owner in advance, because a cross-layer incident with no pre-assigned owner escalates by organization chart instead of by knowledge.

Where many solutions share the same integration estate, the standards live one level up, in Microsoft Integration Architecture for Large Enterprises; this guide’s runbook is the per-solution instance of that discipline.

Common Failure Modes

The same defects recur across hybrid estates, each with an early tell.

• Enterprise logic trapped in a client app. The rule exists once, in a canvas app or a flow, and its second consumer copies it. The tell is a calculation whose two implementations are reconciled by hand each quarter.
• Two sources of truth for one entity. Each side writes to its own store, and the integration papers over the disagreement until an auditor or a customer finds it. The giveaway is a reconciliation spreadsheet with an owner but no end date.
• Credentials standing in for architecture. A shared account or an embedded secret carries an integration because the boundary was never designed. Look for an integration that breaks when a specific person changes their password.
• A custom service without an operational home. It shipped as part of the app project, the project closed, and its incidents now route to whoever remembers it. The clue is a service whose last deployment predates its current owner’s tenure.
• Lifecycles coupled by accident. An app release and an API release must ship the same afternoon or both fail. Watch for a release calendar where the Power Platform and Azure entries share a date on release after release.

How i3solutions Runs a Boundary Review

The review runs as a short engagement with a written recommendation at the end. Discovery first, against your solution rather than a questionnaire: the app and flow inventory as the Power Platform admin center reports it, the data stores and their claimed owners, the integrations and their monitors, and the identities each connection actually uses, read from each environment’s connection list. The five-layer framework is then applied layer by layer, and each finding lands in one of three states: sound, defect with a remediation cost, or unknown with a named owner accepting it.

The recommendation carries one of three verdicts: a boundary already sound for the workloads queued behind it; a scoped remediation with a sequence; or a constraint that sits outside the solution, named as such. i3solutions is a Microsoft Partner with 30 years of delivery experience and has delivered 600+ Microsoft platform implementations. What that buys you is borrowed expertise: pattern recognition from implementations that accumulated the same debt yours is accumulating. Delivery is senior and US-based.

When i3solutions Is Not the Right Next Call

Four situations belong elsewhere.

• The platform choice is still open. If the argument is whether to build in Power Apps or in custom .NET at all, run that decision first; this guide’s framework assumes it returned both.
• A single-platform estate. Where the solution lives entirely inside Power Platform, with no custom services, no external systems of record, and no shared logic crossing team lines, the boundary questions collapse into platform governance: the environment and ALM discipline most platform teams can run internally.
• A data platform dispute. Where the real fight is Dataverse versus SQL Server for a workload, settle the comparison before ruling on sources of truth.
• A decided architecture that needs hands. Where the boundary document exists and you need build capacity, that is a staffing conversation rather than an architecture review.

What is left is the case this guide was written for: a working hybrid solution, growth queued behind it, and no written answer to who owns which layer or which store wins.