Microsoft 365 Copilot App Builder vs. Generative Pages

After the summer, I wrote about Microsoft’s AI-assisted application development tool (generative pages) for Power Platform. This week, Microsoft released App Builder, a similar (vibe coding) tool for Microsoft 365. In it, the user tells the language model, using natural language, what kind of application they want, and the language model generates the necessary code for this.

Absolutely magic.

Let’s take a closer look at this new tool. Let’s compare it to the generative pages functionality we introduced earlier. However, the idea is essentially the same. What is the difference between the two?

Example – Asset Management

Let’s use App Builder to build a simple app to manage assets, such as laptops and phones.

App Builder is found within M365 Copilot (users must have an M365 Copilot license). It is part of the Frontier program, which is activated separately from the M365 admin center.

Compared to Power Platform’s Generative Pages functionality, the functionality is much more accessible. App Builder is for everyone. Generative Pages is aimed at Power Platform makers.

Let’s start with the following prompt.

I need an app for managing company assets using two SharePoint lists as data sources:

- Assets — contains all asset details
- Brands — contains brand names used in the Assets list

Each asset should include the following fields:

- Name
- Brand (lookup from the Brands list)
- Model
- Image
- Location (options: Helsinki, Porto, Barcelona, Home)
- Price (in euros, excluding VAT)
- Assigned User (person-type column)
- Status (options: In use, Available, Broken — use color coding for visual clarity)

The app should:

- Display assets as visually appealing cards
- Allow users to create, edit, and delete assets
- Use #003015 as the brand's main color and #E8EFEA as a light green accent

The UI should be clean and modern, optimized for usability and quick access to asset details.

App Builder starts working. This time it divides the task into 15 parts.

The user experience is simpler than in generative pages. App Builder doesn’t show the code it generates, nor does it provide more detailed information about what the agent was thinking while doing the work. But the app does eventually come out of it.

App Builder tells you where it created the necessary SharePoint lists, which is a significant difference compared to generative pages.

• Generative pages: Always Dataverse as the datasource. The data model (required tables and their columns) is created yourself before starting to build the application.
• App Builder: Always SharePoint list(s) as datasource. App Builder always creates a new SharePoint site and the necessary lists and columns there.

Let’s take a look at what App Builder has done. There’s a dedicated list for brands, just as we asked.

Assets also have their own list.

A few noteworthy observations.

• The asset references the brand using the value of the brandId column. This means that the brand names can be modified without breaking the “relationship”. The language model was able to create its own cheap-price relationship between the two lists.
• The image in the asset is just a text field. Not a SharePoint image or hyperlink field. So this is unusable.
• The asset owner is also a text field. Although I specifically requested that it be a SharePoint Person field.

Editing a created app

An application created with an opening prompt rarely works as we hope. Fortunately, you can further refine the application with additional prompts!

Ask App Builder to update the product image field to the correct data type (image).

Everything looks fine! The application has been updated and now you can also save pictures.

Except we can’t. Saving a new asset fails.

The reason is clear. App Builder didn’t change the data type of the image column.

It did change the application so that it assumes this new field is found in SharePoint.

Next, we ask App Builder to create a new image-type column (Product Image) and use it. Same result. App Builder does change the application and its form, but nothing works because the application and the data model behind it no longer match.

And it doesn’t help even if you create the necessary column in the list yourself.

NOTE: This time the problem is probably the data type of the desired field. You can add basic text fields to lists yourself and instruct App Builder to use them.

Generative pages is still more stable in this respect. However, its task is easier, as the creation of the application and the data model are kept separate.

We are still testing the basic functionality. Asset editing is completely missing, and adding a new asset does not work. However, after a few additional prompts, the application actually works and looks like this.

Adding a new asset.

The generative pages made with the corresponding prompts look like this.

It’s not worth staring too hard at the appearance of the applications. Both tools produces a different-looking application everytime you use them. Then, prompting is used to guide it in the desired direction.

Sharing, using, and modifying the app

You can share the finished app with a colleague. Sharing also gives you access to the SharePoint site behind the app.

Select the user and send them a link.

Please note that the colleague must also have an M365 Copilot license. The shared link opens the application within M365 Copilot.

When a colleague uses the application, the actions are performed through their connection, just as they should be.

My apps can be conveniently found under App Builder, where you can edit them later.

The biggest differences in editing compared to generative pages are:

• the generated code cannot be seen, edited, or compared between iterations
• you cannot go back to the previous step (cancels the previous prompt)

Where are those apps actually stored?

Where are apps created with App Builder stored?

When you create your first app, a new Power Platform environment (Microsoft 365 Copilot App) is automatically created in your tenant.

All apps made with App Builder are stored there.

As usual, you can find a direct link to the application in the additional information about the application.

Using the link, the app created with App Builder will open as Power Apps as usual. Technically, the app can be run without an M365 Copilot license. I wonder if it will soon become clear what license is actually required to use apps created with App Builder.

It’s a safe bet that app made with App Builder is in practise Power Apps code apps.

There is even a version history here, from which you can also go back to different versions.

Summary

What did I get from App Builder after a quick test drive?

Still a bit raw, but so was generative pages 3 months ago.

The world is full of simple apps built on top of a SharePoint list using canvas Power Apps (in the default environment). App Builder is the next generation of them. Generative pages offers a similar tool, but it is now (and I guess it will be) taken further:

• Dataverse as a datasource
• Undo/redo prompts
• The generated code can be viewed and edited
• The application can be created in a development environment and exported from there to production via testing using a solution package.
• etc

There are also all kinds of little hassles to be expected at the beginning.

What if the user doesn’t have permissions to create new SharePoint sites? Is that the end of the game? Who cleans up all the sites created by App Builder? Each experiment generates a new site that is not automatically deleted when the app is uninstalled.

It would be great if the application could be built on top of an existing SharePoint list. This way, the missing application could be built directly on top of the data already collected.