The prototype took a developer at Langkloof Financial Cooperative, a fictional regional financial-services cooperative, two days. Langkloof's branch staff needed a simple tool to follow up incomplete onboarding cases: list the cases for my branch, show what is missing, let me record a call and set a reminder. Thabo, a developer on the onboarding team, built it in React with an AI coding assistant, connected it to the cases table in Dataverse and a SharePoint list of branch contacts, and published it as a Power Apps code app to his development environment. The branch manager who saw it on Friday asked whether it could be in all fourteen branches by the end of the month.
It could not, and the reasons had nothing to do with the code. The SharePoint data source was bound to Thabo's personal connection. It sat in the environment's default solution. Its source lived only on his laptop. Nobody had checked whether branch staff had the licence it needed. Each of these was a short decision on day one and a week of rework on day thirty.
This article is a field note on the decisions that make a code app production-ready, and why they come before the first component. Every product fact below was checked on Microsoft Learn on 5 November 2026. The platform is changing quickly, so check again before you rely on any of it.
What code apps are, according to Microsoft
Microsoft's code apps overview (updated 23 September 2026) describes them as a way to build custom business web apps in a code-first editor such as Visual Studio Code, with frameworks such as React or Vue, and run them on the Power Platform. The app authenticates through Microsoft Entra ID, calls Power Platform connectors directly from JavaScript, and follows the organisation's managed-platform policies, including sharing limits, Conditional Access and data loss prevention. Microsoft announced general availability on its Power Platform blog in February 2026.
Three practical points from the documentation shape everything else:
- An administrator must enable code apps per environment in the Power Platform admin center, or at scale through environment groups and rules.
- End users need a premium entitlement: a Power Apps Premium licence, pay-as-you-go, an App Pass, or auto-claim of an available premium licence.
- The tooling has changed. The current Power Apps CLI is npm-based and uses commands such as
pa app init,pa app add data-sourceandpa app push. The olderpac codecommands in the Power Platform CLI are marked as preview, and Microsoft's reference page says the npm-based CLI will replace them. Older tutorials and samples may use the old commands.
First, is a code app the right app type?
A code app is one option, not the default. CloudNala's working rule, which is our analysis rather than Microsoft guidance, is to choose by who will maintain the app:
| If the app will be maintained by... | Consider | Why |
|---|---|---|
| Business makers in the branch network | A canvas app | Makers can change it without a developer |
| A team whose process lives in Dataverse tables, forms and views | A model-driven app | The process and security model come from the data |
| Professional developers who need a custom interface | A code app | Full control of the interface and logic, inside platform governance |
Langkloof chose a code app because the onboarding team already had developers, the branch interface needed to work well on small tablets, and the team wanted the same review and testing discipline as the mobile app. That choice carries obligations a canvas app would not: someone must own a build, a dependency list and a repository. Citizens build discusses why business users belong in software creation; the point here is that the choice should be made deliberately.
The decisions that come before the first component
1. Environments and enablement. Decide which environments exist (at least development, test and production), confirm code apps are enabled in each, and decide who may publish to which. If you want the app in a solution, the environments need Dataverse: Microsoft notes that in an environment without Dataverse the app publishes without a solution, and an explicit solution ID fails. A prototype in someone's personal or default environment is not on a path to production.
2. Licensing. Confirm that every intended user has a qualifying entitlement before the pilot, not after. At Langkloof, two branches used staff on licences that did not include premium apps. That was a budget conversation, and it needed to happen before the branch manager's deadline was set.
3. The solution. Microsoft's ALM guidance for code apps explains that pa app push can place the app in a Dataverse solution, which then moves between environments by export and import. If you do not name a solution on the first publish, the CLI uses the environment's preferred solution, falling back to the default solution. Microsoft recommends setting a preferred solution for predictable ALM. Langkloof now passes the solution ID explicitly, through the PA_CLI_SOLUTION_ID environment variable in its pipeline, so that no publish depends on someone's environment settings. Note that the CLI accepts the solution ID, a GUID, not its name, and that all of this assumes a Dataverse-enabled environment.
4. Connection references, not personal connections. A connection is tied to a person and an environment. A connection reference is a solution component that points to a connection, so each environment can bind its own. The CLI supports adding a data source with --connection-ref and --solution-id. This applies to connector-backed data sources such as SharePoint or SQL Server; Microsoft's guide notes that native Dataverse tables do not use a connection ID, connection reference or dataset, because they bind to the environment's own Dataverse. Thabo's SharePoint source used his own connection ID, a common reason a code app works in development and fails everywhere else.
5. Source control from the first commit. Here the documentation contains a detail that changes the plan. Microsoft states that code apps do not support Power Platform's Git integration. The app's source therefore lives in your own repository, with your own review and build, and the solution carries the published app between environments. Two systems of record need to stay in step, and someone must own that.
6. Data access and schema. When you add a data source, the CLI generates typed TypeScript models and services from the source's metadata, including native Dataverse tables. That is useful grounding: the app and any coding assistant work against the real schema rather than guessing. When the schema changes, pa app refresh data-source regenerates the files. Treat a schema change as a code change, reviewed and tested.
7. Policy and network assumptions. The overview lists limitations that matter for security reviews. Compiled app assets are served from a publicly accessible endpoint that does not support IP-based restrictions, so Microsoft points to Conditional Access, for example blocking by location, if access must be restricted. The overview also says code apps do not yet support Secure Implicit Connections or Power BI data integration, do not support SharePoint forms integration, and are not supported in Power Apps for Windows. Separately, the data-connection guide says the Excel Online (Business) and Excel Online (OneDrive) connectors are not yet supported. None of these is a reason not to proceed; each is a fact the security reviewer should see before the pilot.
From developer laptop to fourteen branches
Langkloof's path now has four stages. A pull request to the repository triggers a build and the automated tests. A merge to the main branch publishes to the development environment with pa app push and the solution ID. The solution then moves to test and production through Power Platform pipelines, which Microsoft's ALM page describes as running preflight checks for dependencies and connection references. In each environment, the connection references bind to service connections owned by the platform team, not by Thabo.
Publishing from a pipeline needs an identity. The CLI reference documents a non-interactive publish with a service principal and notes that the service principal needs edit access to the app. That identity should be scoped to the environments it publishes to, in the same spirit as least-privilege pipelines.
Where AI coding assistants fit
Microsoft's own data-connection guide suggests using an agent in your editor, such as GitHub Copilot agent mode, to wire generated services into the app after data sources are added. That is a sensible use. The assistant works well against generated typed models, and the review gate is the same as for any other code.
What an assistant should not decide is any of the seven items above. It will happily hard-code a connection ID or publish to whatever environment is active. The production decisions belong in the repository's documentation and pipeline configuration, where the assistant reads them as constraints. AI makes software easier to create, not easier to trust explains why the trust work does not shrink when generation gets faster.
A production checklist
| Check | Owner | Evidence |
|---|---|---|
| Code apps enabled, and Dataverse present, in each target environment | Power Platform admin | Admin center setting or environment group rule |
| Users hold a qualifying entitlement | Licence owner | Licence report for the pilot group |
| App published into a named solution by ID | Developer | Pipeline variable and push log |
| Connector-backed sources (such as SharePoint) use connection references; native Dataverse tables bind to the environment | Developer | power.config.json and solution contents |
| Source in a repository with review and build | Team lead | Branch protection and pipeline run |
| Pipeline identity scoped to its environments | Platform team | Role assignments |
| Security review has seen the documented limitations | Security | Signed review note |
| Schema changes regenerate and retest the app | Developer | Refresh step in the change checklist |
From prototype to production gives the broader trust checklist for AI-built software. This one is specific to code apps.
Key points
- A code app's production readiness is decided before the first component: environment, licensing, solution, connection references and source control.
- Use the current npm-based Power Apps CLI; the
pac codecommands are marked preview and are being replaced. - Publish into a named solution by ID in a Dataverse-enabled environment, and bind connector-backed data through connection references so each environment uses its own connections.
- Code apps do not support Power Platform Git integration, so your repository and the solution must be kept in step deliberately.
- Show the security reviewer the documented limitations, including the public asset endpoint, before the pilot.
Next: Part 4, Use AI to learn, not merely to receive answers. All parts are on the series page.
How CloudNala can help
CloudNala helps teams take Power Platform code apps from a working prototype to a governed production service. We set up environments, solutions, connection references and a repository-to-pipeline promotion path, review licensing and the documented platform limitations with your security team, and leave you with a checklist your developers and coding assistants follow from the first commit.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Architecture Practice Review or write to us at consult@cloudnala.co.za