Power Apps, Dataverse, Azure, and Custom APIs: The Enterprise Architecture Boundary in One Hybrid Solution

By Michael Branson | August 23, 2026

Quick answer. The Power Apps and Azure architecture boundary in a hybrid enterprise solution is drawn across five layers: experience, data, services, integration, and operations. Each layer gets one named owner, one source of truth ruling for the data it touches, and one lifecycle, written down before the first integration ships.

The decision to combine platforms has already been made in the rooms this page 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 page 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 Page Owns, and What It Hands Off

This page 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 page. 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 page 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 page does not run. Estate-wide integration standards live in the practice’s reference material linked further down. Conditional access and application consent policy are identity-layer decisions, left to that layer. This page sits under Power Apps Software Development.

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 Power Platform hybrid architecture that results 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 page is that record’s template.

The Five-Layer Boundary Framework

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

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.

If drawing this line for a specific solution is the work in front of you, bring it to a working session. Bring your app inventory, the connector list, and the workloads queued behind the current build. What comes back is a written boundary read you can circulate: which assets sit on the right side of the line, which are already over it, and what moving them costs. Two of its possible findings are worth naming in advance: that your boundary is already sound, or that the constraint sits outside Power Platform and is somebody else’s work. Talk to a senior Power Platform architect

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.

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. If the register does not survive contact with the ERP team, an outside read settles it faster than a fourth internal meeting. 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. Talk to a senior Power Platform architect

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.

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 Azure Power Platform integration architecture 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 page’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 has been a Microsoft partner since 1997 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. Enterprise Delivery Assurance, the discipline behind landing work on-time, in-scope, and in-production, governs the engagement. Delivery is senior and US-based. The record sits at Explore Our Work.

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 page’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 page was written for: a working hybrid solution, growth queued behind it, and no written answer to who owns which layer or which store wins. Bring the app inventory, the integration list, and the incident that made this urgent. A session against the five layers settles whether the boundary is the constraint. The endings are unchanged: your boundary is already sound for what you plan to build next, or there is a scoped remediation with a sequence and owners, or i3solutions saying this is not our work. Talk to a senior Power Platform architect

Frequently Asked Questions

What should Power Apps own versus Azure in a hybrid solution?

Draw the boundary across five layers: experience, data, services, integration, and operations. Power Apps owns the experience layer: screens, task flows, approvals, and the data capture behind them, with Dataverse holding the application’s working records. Azure services and custom APIs own the services layer: logic more than one consumer applies, processing that runs long or at volume, and integrations that carry regulatory weight. The integration layer connects the two through governed contracts rather than direct database access, and the operations layer gives the whole solution one accountable service owner. The working test is the second consumer: the day a dataset serves more than the one app it was built for, its ruling belongs in the data layer’s register, and the day a rule does, the rule belongs in the services layer.

When do custom APIs belong in a Power Apps architecture?

A custom API in a Power Apps architecture earns its place under four conditions. First, shared logic: a calculation or business rule that two or more consumers apply belongs behind one contract, because copies drift. Second, documented platform limits: workloads that push past delegation bounds or service protection limits need infrastructure scaled for them. Third, asynchronous or long-running processing that a screen should not wait on. Fourth, integrations where the contract itself matters: versioning, audit, and error behavior that a governed API states explicitly. The platform then reaches that API through a custom connector rather than through credentials to the systems behind it.

How do we define the boundary between Dataverse and our systems of record?

Write a source-of-truth register: one row per business entity, naming the authoritative store, the direction of synchronization, the conflict rule, and a reconciliation owner. Entities an enterprise system already owns usually stay there, with Dataverse holding a working copy under a declared refresh contract, or surfacing the external data through virtual tables without copying it. The register also rules on identifiers: which key crosses layer boundaries and where the single mapping between key systems lives. Unknowns are recorded as unknowns with a named owner, which keeps the register honest and auditable. The platform question of whether a workload belongs in Dataverse or SQL Server is a separate comparison, settled before this register is written. Revisit the register whenever a new system joins the solution, because each arrival re-opens the ownership question for the entities it carries.

How is identity handled across Power Apps and Azure services?

Two identity postures coexist by design. 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 the app reaches what the user is entitled to reach, with any shared-credential or service-principal connection named as a declared exception. The services and integration layers run on service identity: between Azure components, managed identities remove the manual secret handling Microsoft documents as a known source of security issues and outages. The boundary document records each crossing point: the API decides what a user’s context entitles, and the data register says what a service context touches. Shared accounts and embedded passwords are boundary defects.

How do we stop integration debt from building up in a hybrid estate?

Integration debt accumulates where connections ship without entering a record, so the control is an inventory with teeth. Every integration gets a row naming its trigger, its volume class, its monitor, its owner, and the identity it runs as before it ships, and a connection without a row fails review. Route new connections through the governed seams, custom connectors and published APIs, rather than direct store access, so each new consumer lands on a contract instead of a copy. Review the inventory on a cadence and retire what nothing consumes. The cultural half matters as much as the register: the day a point-to-point shortcut is faster than the governed path, makers and developers alike will take it, so keep the governed path cheap. Cheap here means documented, discoverable, and faster than the workaround.

Related Reading

• Enterprise Power Apps Development Services, the delivery practice behind the experience layer
• Azure Development Services for Regulated Enterprise Workloads, the delivery practice behind the services layer
• Custom Application Development Services for Enterprise Performance, where the custom side of the boundary is built

About the Author

Michael Branson co-founded i3solutions and brings executive, operational, and technical perspective to organizations whose Microsoft estates carry regulated content, audit obligations, and uptime the business depends on. He works with enterprise teams on the architecture decisions that determine whether a platform investment holds its value.