Power Apps Code Apps in Practice: Recreating Model-Driven App Patterns

Power Apps Code Apps went from preview to general availability in record time. With that, Microsoft has sent a clear signal that it is taking this technology very seriously.

In fact, Code Apps are something of a small revolution. They allow pro-code developers to deliver custom web apps directly within a Dataverse environment without the need to implement authentication libraries.

But that is not all: Low-code developers can benefit from them as well. With tools like GitHub Copilot and Claude Code, you no longer necessarily need to understand a programming language such as React in order to build full-blown web application. Instead, you can simply describe the features you want in a prompt and have them implemented.

This will fundamentally change the way how apps will be implemented in the future. React Fluent UI components can be integrated into Code Apps and open up entirely new possibilities for designing user interfaces such as accordions, cards or TreeViews.

Motivation

There is, however, one important point to consider: At the time of writing, Power Apps Code Apps are stand-alone apps. That means they are not integrated into a model-driven app, but exist as independent applications, similar to canvas apps. There is also no custom page in a model-driven app to represent a code app.

But what if you still need the typical built-in functionality of a model-driven app upfront, such as filtering records in a data grid? One option would be to add a button to the model-driven app or try to integrate the app through an iframe.

This article explores another approach: recreating typical model-driven app functionality directly inside the custom app. The goal is to assess how much effort this requires and how quickly something like this can be implemented, not to reinvent the wheel, but to demonstrate the capabilities and the power of Code Apps. And of course also to show that, for many use cases, you no longer need a model-driven app as the entry point.

PoC: Table Browser App

The goal was to build an new code app "Table Browser" from scratch which demonstrates that a standalone Power Apps Code App can reproduce familiar Model-Driven-App-style functionality, such as filtered and searchable record lists with the same look and feel like Model-Driven-Apps. This can serve as an entry point and opens the door to building a fully fledged standalone app with a much richer user experience, including features such as tree views and other advanced interface patterns that are difficult to realize in a traditional Model-Driven App.

It is also a proof of concept: each feature was chosen to answer a specific question about what Code Apps can do. A secondary goal was to evaluate these two tools in a real-world scenario and gain hands-on experience with AI-assisted development.

The entire app was built in a single Saturday — using both GitHub Copilot and Claude Code as AI coding assistants. Fun fact: Claude Code estimated the development effort for the entire app at 12 to 15 days if implemented by a senior developer without the help of AI.

 

Proof Points

• Performance: Can a Code App render large Dataverse record sets noticeably faster than a Model-Driven grid? Yes.
• Infinite scroll: How much code does it take to implement demand-driven pagination? Very little — a scroll event plus a getAll call with top and skip.
• Metadata access: How easy is it to read column metadata at runtime? One SDK call to retrieveMultipleRecordsAsync on EntityDefinition gives you full attribute detail.
• View definitions: Can a Code App read the default system view and use it to determine which columns to show? Yes — savedquery records expose the column layout as XML, which the app parses to build its default column set.
• Form definitions: Can a Code App reconstruct the default form layout — tabs, sections, fields — without hardcoding it? Yes — systemform records contain the full form structure as JSON and XML, which the app uses to render the record detail dialog.
• Column persistence: Can user preferences be stored in Dataverse instead of localStorage — cross-device, without a custom table? Yes, via personal views (userquery).

Key capabilities

• Browse records from multiple Dataverse tables with infinite scroll and client-side search
• Inspect column metadata and field properties (schema view)
• Customize visible columns per table — persisted as personal views (userquery records) in Dataverse
• View full record details in a form-based dialog with tabs and sections
• Switch between list (DataGrid) and card grid layouts
• Light/dark mode, display density, and accent color theming (persisted to localStorage)

UI Features

The goal was to implement the same look and feel that we know from Model-Driven-App. This can easily be achieved by using the  React Fluent UI components library. The following chapters show which features have been implemented. 

List View

 

• The app uses the metadata to look for the default view of the table and shows all columns defined there.
• Columns width can be changed by drag and drop.
• Columns can be sorted. If sorted, an api call is used for server side sorting
• Smooth paging: Scrolling to the end of the list reloads the next page of data (e.g. the next 50 records)

 

Search and highlighting

 

• Search was implemented with a single field which searches in all text fields
  • This was easier to implement
  • A filter below every column, as in model driven apps could be another option for the future.
• Highlighting the matched text was very easy to implement, so this functionality was added as well, even though it does not exist in model-driven apps

 

Column selection and reordering
 

 

• A modal dialog window can be used to select the columns to display
• A drag and drop component can be used to reorder the columns. The @dnd-kit/sortable library was used to implement this feature
• The adjusted view is updated in the Dataverse personal view

 

Card View

 

• A Card View as an alternative to a List View was implemented
• This was quite easy because a card already exists as a UI component in the React UI Components
• This view is especially useful for data with images

 

Detail View Edit Dialog

 

• A detailed review was implemented to show and edit the current record
• The code dynamically parses the system form record to create the layout dynamically from the defaults form definition (including tabs)
• Field types text, text area, option set, lookup, yes/no, date/time are supported and fully working
• Of course, the form doesn't support PCF or sub grids.
• An alternative approach approach for the future, could be to redirect to a detail view, like a Model-Driven-App does 

 

Table Column Definitions

 

• A column meta data list was implemented
• It automatically shows all columns of the table with display name, data type, required, and description
• It proves that metadata can easily be fetched by the @microsoft/power-apps/data lib (for code apps)
• The column metadata can also be filtered
• The screenshot shows the list in dark mode. Of course, dark mode is available for the whole application. 

 Settings dialog 

 

• A small settings dialog was implemented for the settings of dark mode, display density, and accent color
• This was very easy to implement since dark mode, accent color and density are just properties in the React Fluent UI library
• The settings are stored in the local storage of the browser for simplicity

Lessons learned with GitHub Copilot and Claude Code

The project was developed almost entirely in "interactive agent-driven mode".
Both GitHub Copilot and Claude Code were used as active development assistants during the entire process.

The agents were involved in:

• Concept discussions
• Implementation
• Refactoring
• Architectural decisions
• Documentation improvements
• Iterative improvements to the collaboration workflow

In addition to generating code, the agents were also used to discuss best practices and improve the documentation and structure of the project itself. Both agents used the same model (Claude Sonnet 4.6), but produced different results due to their overall architectural differences.

Claude Code

Overall, Claude Code produced more consistent and reliable results.

Strengths included:

• Better architectural reasoning
• More structured implementations
• Clearer explanations
• Higher-quality refactorings

Claude Code was particularly strong when working across multiple files or when performing larger structural changes in the project. In the beginning it introduced reusable UI components even before having instructions to do so.
When working with Claude Code, development sessions occasionally reached usage limits. This required temporarily switching back to GitHub Copilot until the session limit reset. As a result, the project naturally evolved into a mixed workflow where both tools contributed to the final implementation.

GitHub Copilot

GitHub Copilot performed well for smaller tasks but showed some weaknesses when acting as a full development agent.

Some common issues included:
- Guessing instead of reasoning
- Repeating the same incorrect approach multiple times
- Getting stuck in loops when a problem was not clearly defined

However, some of these issues were likely influenced by better instructions given to the agent (e.g. links to the official documentation, instructions to always look there first) 

At the beginning of the project, important rules were not yet defined, for example:
- Asking for confirmation before large refactorings
- Explaining architectural changes before applying them
- Avoiding speculative changes

Once clearer rules were established, the results improved.

Architecture

The architecture naturally follows the architecture of Power Apps Code Apps. Services for accessing data and model classes were generated using the pac tool.

The following architecture diagram was generated with Claude Code. This no longer has to be done manually by hand either...

Conclusion

It is extremely impressive how quickly and easily a Power Apps Code App can be developed with GitHub Copilot or Claude Code. What makes development so fast and straightforward is the combination of coding agents with an intelligent framework for app development.

Throughout the entire development process, there was never any sense of working with an unstable product or with something that had only recently reached general availability. There were no crashes at all, and deploying the app via solution to another environment also worked flawlessly.

Only in a few places does the API appear to be not entirely complete yet. For example, RetrieveRecordAsync did not work, so a workaround had to be implemented using GetAll with a filter expression. However, the most important actions for loading, filtering, and saving data are already very stable.

Code Apps will fundamentally change the way we build apps in Dataverse environments and across the Power Platform. Canvas Apps may soon become obsolete and be replaced by Code Apps. There may also be more options in the future to integrate Code Apps into Model-Driven Apps. Until then, however, both can coexist peacefully side by side.