Fix the workflow and roles before assigning ownership
Use the same small departmental workflow in every model: an authenticated user reads assigned synthetic records, changes one status through an approved data connection, and an operator releases one reviewed change.
Assign these roles even when one person fills more than one:
- Provider: operates the managed platform service.
- Platform administrator: controls environments, policies, identity integration, and service configuration.
- Application maintainer: owns app definition or code and dependencies.
- Data owner: approves data scope, connection, retention, and recovery.
- Business owner: accepts workflow behavior and user roles.
- Release owner: approves and verifies production changes.
- Second operator: proves that handoff knowledge is durable.
An owner is accountable for an outcome, not merely named on a diagram.
Read the documented platform boundaries
Microsoft describes canvas apps as business applications assembled in Power Apps and connected to sources such as Dataverse, SharePoint, Excel, and SQL. The customer still chooses who receives the app and which data connection and roles apply.
For canvas apps, saving and publishing are separate. Microsoft's current publish documentation says saves create version-history entries, publishing makes a saved version available to shared users, and an earlier version can be restored and republished. Those app-version controls do not restore changed business data.
Code apps use customer web code within the Power Apps host and require developer tooling plus an environment option enabled by a Power Platform or environment administrator. The current overview also lists limitations, including no Power Platform Git integration and a publicly accessible compiled asset endpoint; authentication and access design still need direct review.
The customer-cloud reference uses React, Node, Azure App Service, a customer repository and pipeline, Microsoft Entra ID, and customer-owned data services. Azure's shared-responsibility guidance places the PaaS operating system, runtime, and middleware with Microsoft while retaining customer responsibility for data, identities, settings, access, and controlled application components.
Use a responsibility matrix as a starting assignment
This table is an editorial starting assignment inferred from the documented boundaries. The accountable platform owner must replace role labels with people and validate them in the actual environment.
| Layer | Canvas app | Code app | Customer-cloud React |
|---|---|---|---|
| App definition | Maker or app maintainer; business owner accepts behavior | Professional developer owns source and client dependencies | Development team owns frontend, API, schema, and dependencies |
| Platform policy | Power Platform admin owns environment and connector policy | Power Platform admin enables and governs code apps | Cloud platform owner governs subscription, network, policy, and App Service |
| Identity and access | Platform admin configures platform boundary; app and data owners verify effective roles | Platform admin and developer jointly own Entra and app authorization | Identity/platform team and developer own Entra integration and server authorization |
| Data connection | Data owner approves source and scope; maker maintains connection | Data owner approves source; developer maintains client and connector behavior | Data owner owns scope and recovery; development team owns data access code |
| Release | Maker prepares version; release owner approves publish and verifies Live version | Developer builds change; release owner verifies environment and published version | Pipeline builds immutable artifact; release owner approves promotion and running identity |
| Updates | Provider updates service; app maintainer tests app compatibility | Provider updates host/client; developer owns package and code compatibility | Provider updates PaaS runtime; development team owns app and dependency updates |
| Incidents | Platform admin and app maintainer triage; provider handles service faults | Platform admin and developer triage host, client, and app evidence | Platform and development teams separate service, runtime, and app diagnosis |
| Recovery | App maintainer handles version rollback; data owner owns data recovery | Developer owns app rollback; data owner owns data recovery | Release owner rolls back artifact; data owner runs separate recovery |
| Handoff | Maker transfers app, connections, roles, environment, and runbook | Developer transfers repository, tools, environment, and operating packet | Teams transfer source, pipeline, cloud resources, identity, data, and runbooks |
Shared ownership needs one decision-maker and an escalation path. “IT and the maker” is not an assignment until each side knows which action it can perform.
Ask the same maintenance questions in every model
For each column, require direct answers:
- Which maintained artifact changed, and who reviews it?
- Where are allowed and denied roles enforced?
- Who owns the data or connector identity and effective scope?
- Which version is live, and who approved it?
- Who handles a provider or dependency update?
- Where does a controlled failed request become visible?
- Can a second operator roll back the app change and find separate data recovery without the builder?
Unavailable evidence stays unavailable. Do not replace it with a vendor feature claim.
Notice the different maintenance centers
Canvas maintenance centers on the app definition, formulas, connections, sharing, environment policy, and the business data source. Less conventional source code does not mean less ownership.
Code-app maintenance adds ordinary web source and package responsibilities inside the Power Apps environment and host boundary. The platform administrator and professional developer therefore need an explicit interface, especially for enablement, identity, publishing, and updates.
Customer-cloud React maintenance centers on the repository, build artifact, pipeline, PaaS configuration, application telemetry, identities, and data services the customer assembles. Azure App Service manages underlying PaaS layers, not the complete application.
These are differences in where work sits, not a finding that one model requires less total care.
Test the assignments with one equivalent exercise
Run the same seven actions in non-production:
- change one validation rule and inventory maintained artifacts;
- allow one synthetic role and deny another;
- read and update one synthetic record;
- promote one reviewed change while retaining the prior version;
- apply or observe one documented platform or library update;
- trigger one safe failed request and locate the response owner; and
- revert the app change, locate data recovery, and time a second-operator handoff.
Record model and version, operator role, elapsed time, observable result, evidence location, failure signal, unresolved dependency, and corrective owner. Do not aggregate the rows into a winner.
Evidence boundary for this draft
Official documentation was rechecked on August 4, 2026 and the identical test
protocol is frozen. No canvas, code-app, or Azure/GitHub reference environment
was acquired. Every runtime row remains Not observed.
The responsibility matrix is therefore a reviewable assignment hypothesis, not a measured comparison. This review version makes no cross-model runtime finding; a platform owner must run the protocol in all three equivalent environments before adding one.
Ownership review checklist
- Reference architectures and exclusions are fixed.
- Every layer has one accountable decision-maker and escalation path.
- Provider duties are separate from customer application duties.
- App rollback is separate from data recovery.
- Documentation, observed behavior, and editorial assignment are labeled.
- Equivalent roles and non-production environments are available.
- The same seven actions and failure thresholds are used in every model.
- No score, winner, or recommendation precedes comparable evidence.
Frequently asked questions
Should the citizen maker own a canvas app forever?
Not by default. The maker can maintain the definition when that is an assigned role, but platform policy, data authority, release approval, incident response, and recovery still need durable owners and a backup operator.
Does a code app belong entirely to the developer?
No. The developer owns source and application behavior, while environment, identity, platform policy, data authority, and business acceptance cross other roles.
Does App Service remove the need for a platform team?
It removes management of underlying PaaS operating-system and runtime layers. The customer still owns the application architecture and the cloud components, identity, data, delivery, telemetry, and procedures it controls.