TL;DR
Code Apps can bring custom web development into Power Platform visibility, but they do not automatically govern the source repository, dependencies, review process or build pipeline. A mature CoE must connect Power Platform governance with software engineering governance before Code Apps scale.
Introduction
Code Apps are often positioned as an answer to shadow IT. That claim has merit: the deployed app can live in an approved Power Platform environment, use governed connectors, follow sharing controls and move through solutions and pipelines.
However, there is a risk in stopping the argument there. An app can be visible in Power Platform while the source repository, third-party dependencies, build scripts, code review practices and operational knowledge remain invisible to the CoE.
That is not traditional shadow IT. It is shadow engineering: a sanctioned application asset supported by an engineering process the organisation cannot fully see, govern or sustain.
Why the traditional CoE playbook is incomplete
Most Power Platform governance models are designed around environments, makers, connectors, data policies, sharing, solutions and licensing. Those controls still matter for Code Apps. Microsoft confirms support for DLP at launch, Conditional Access, sharing limits, app quarantine, tenant isolation and health metrics.
But Code Apps also introduce a separate engineering lifecycle. The front-end is authored locally as a web project. Microsoft currently supports solution and pipeline-based ALM, while also stating that native Power Platform source code integration and solution packager support are not available.
That creates two related but distinct assets: the deployed Power Platform application and the source code used to produce it. A CoE that governs only the first has only half the picture.
The two control planes of a Code App
| Control plane | What it needs to govern |
|---|---|
| Power Platform control plane | Environment enablement, app sharing, connections, connection references, data policies, Conditional Access, solutions, pipelines, health metrics and licensing. |
| Engineering control plane | Repository ownership, branch protection, code review, dependencies, tests, build configuration, release evidence, technical documentation and support ownership. |
The enterprise control model only works when these two planes meet. If they remain separate, the organisation may know that an app exists but still be unable to reproduce, review or safely change it.
How Code Apps governance should work
A practical governance model does not need to make every Code App slow to deliver. It needs to make the important decisions visible and repeatable. The following eight controls provide a useful starting point.
Classify the workload before approving the technology
The first control is architectural. Require teams to explain why Code Apps are necessary instead of canvas or model-driven apps. The case should be based on experience complexity, lifecycle, supportability or engineering requirements, not developer preference.
This is where the decision framework from Part 1 becomes a governance tool. It prevents the platform from accumulating custom code where lower-complexity options would meet the requirement.
Control where Code Apps can be built
Microsoft allows administrators to enable Code Apps at environment level and manage the setting at scale through environment groups and rules. That gives platform teams an explicit control point.
Use it. Do not enable Code Apps everywhere by default. Start with approved development environments, align the setting with the environment’s purpose and define which teams are allowed to publish.
Name the owners of both the app and the repository
Every Code App needs at least two forms of ownership: a business or product owner for the outcome and a technical owner for the codebase and release process.
Product owner: Owns value, prioritisation, funding and business acceptance.
Application owner: Owns the Power Platform asset, connections, sharing and operational support.
Repository owner: Owns source access, branch policy, review standards and continuity.
Data owner: Approves data access and sensitivity assumptions.
One person can hold more than one role, but no role should be left implicit.
Treat dependencies as governed design choices
A Code App can use modern front-end frameworks and a normal package ecosystem. That is a major strength, but every dependency becomes part of the product’s maintenance and security surface.
A CoE does not need to approve every minor package manually. It should require a documented policy for package sources, version management, vulnerability checks, licence review where appropriate and emergency patch ownership.
The goal is not bureaucracy. It is to avoid discovering during an incident that nobody knows which third-party code is in production or who can update it.
Govern connections and portability together
Microsoft’s connection reference guidance allows Code Apps to bind to solution components instead of user-specific connections, improving portability between development, test and production.
That should become the default enterprise pattern where supported. It reduces environment-specific rework and makes ownership easier to reason about.
However, connection references do not solve inappropriate permissions or unclear identity design. The CoE still needs standards for user connections, shared connections, service identities and the permissions each connected system grants.
Make solutions and pipelines non-negotiable for production
Microsoft documents Code App ALM through non-default solutions and Power Platform Pipelines. Pipelines can promote the solution through development, test and production with preflight checks for dependencies and connection references.
This is where governance should be firm: production should not become a development target. Code should be built and tested in lower environments, then promoted through an approved release path.
This principle is consistent with the broader guidance in Stop giving developers System Administrator access just so they can deploy and Power Platform least privilege. Deployment convenience is not a valid reason to normalise permanent production privilege.
Connect platform monitoring to product monitoring
Microsoft makes Code App health metrics available through Power Platform and supports Application Insights for deeper telemetry. Governance should define the minimum monitoring required by the workload class.
Low criticality: Platform health, an owner and a basic support path.
Business-critical: Platform health, application telemetry, dependency monitoring, a support rotation and incident thresholds.
Regulated or sensitive: Documented audit expectations, access reviews, incident evidence and retention aligned with organisational policy.
The app should not be considered operationally ready simply because it has been successfully deployed.
Design retirement before launch
Every Code App should have an exit path. The organisation needs to know how it will revoke access, disable connections, archive source, retain required data and remove the application when it is no longer needed.
This is especially important for custom code. An orphaned canvas app is a support problem. An orphaned Code App can also include an abandoned repository and dependency chain.
Do Code Apps end shadow IT?
Not on their own.
Code Apps can reduce shadow IT by giving professional developers a sanctioned route into Power Platform. The app can live in an approved environment, use platform controls and participate in enterprise ALM. That is a real improvement over an unknown web app hosted outside organisational visibility.
But Code Apps only improve control when the engineering lifecycle is also visible. Without repository ownership, review gates, dependency policy and support continuity, the organisation has moved the hidden risk rather than removed it.
Core opinion: Code Apps improve enterprise control only when Power Platform governance and software engineering governance meet in the middle.
A minimum production-readiness checklist
The workload has a documented reason for using Code Apps.
The app is built in an approved, purpose-specific environment.
Business, application, repository and data owners are named.
The source repository is organisationally owned and access-controlled.
Peer review and test evidence are required for release.
Dependencies are inventoried and included in vulnerability management processes.
Connections and connection references follow an approved identity pattern.
Data policies and CSP settings have been reviewed.
The app is included in a non-default solution.
Deployment uses an approved pipeline through test and production.
Production makers do not require standing administrative access.
Monitoring, incident ownership, rollback and retirement are documented.
Expected users and Power Apps Premium licensing are confirmed.
Build a CoE developers will use
Governance needs to be usable. A CoE that responds to Code Apps with vague prohibitions and long review queues will encourage teams to work around it.
A stronger model is to provide paved roads: starter repositories, approved patterns, example CSP rules, connection reference guidance, release templates, architecture office hours and a clear production-readiness checklist.
The goal is not to make developers ask permission for every line of code. It is to make the safe path faster than the hidden one.
Final thoughts
Code Apps do not simply add another app type to Power Platform. They connect two operating models that organisations often govern separately: the Power Platform estate and the software engineering lifecycle.
That connection is the opportunity. It gives professional developers a managed application platform without forcing every custom experience into a separate hosting model.
It is also the risk. If the CoE governs only the deployed app, shadow engineering can grow behind an apparently compliant Power Platform asset.
The answer is not fewer Code Apps. It is a better playbook, one that treats the app, code, data, release and support model as one governed product.
Before enabling Code Apps broadly, compare your current CoE controls against the production-readiness checklist above. To discuss how Code Apps could fit into your environment, contact the Arinco team.
Frequently asked questions
Are Code Apps governed by Power Platform?
Yes. Microsoft documents support for controls including sharing limits, app quarantine, DLP enforcement during launch, Conditional Access, tenant isolation and health metrics. The source repository and engineering workflow still require separate governance.
Can Code Apps be deployed through Power Platform Pipelines?
Yes. Once included in a solution, Code Apps can be promoted through Power Platform Pipelines with dependency and connection reference preflight checks.
Does Power Platform Git integration manage Code App source?
Not currently. Microsoft states that Code Apps do not support Power Platform source code integration. Use an organisational Git repository and govern it directly.
Do Code Apps require Premium licensing?
Microsoft’s current overview states that end users who run Code Apps need a Power Apps Premium licence. Confirm current commercial terms before production rollout.
What is shadow engineering?
Shadow engineering is hidden or weakly governed software delivery behind a visible application asset. For example, an app may be registered in Power Platform while its repository, dependencies, review process or support ownership remain unclear.
