Copilot on the Power BI Report Canvas vs. Modern Report Builder

(This is the second post in a three-part series on how AI is changing the way we build solutions in Microsoft Fabric. The first post explored the new unified Copilot in Fabric and Project Osmos help build and transform data, moving from AI assistance toward agentic execution. This second post will look at building reports and analytical applications, comparing Copilot on the Power BI report canvas with Modern Report Builder. The third post will focus on using AI to build semantic models, ontologies, and Fabric Data Agents—the pieces that define what the data means and help people ask useful questions about it.)

At first glance, Modern Report Builder might look like the next version of Copilot on the Power BI report canvas. Both let you describe what you want using natural language. Both can produce an experience containing charts, tables, and business metrics. Both can start from a trusted Power BI semantic model.

But the most important difference is not how you prompt the AI. It is what you are building.

Copilot on the report canvas helps you create and edit a native Power BI report. Modern Report Builder, the name used for the experience demonstrated at FabCon, is intended to help you create a custom analytical application using Fabric Apps. Microsoft describes the latter as agentic app creation in Power BI Desktop.

That distinction changes what comes built in, what you need to implement, and who will maintain the result. My starting recommendation is straightforward: use a native Power BI report when it meets the requirements; move toward a custom application when the requirements justify the additional responsibility. A more impressive demo is not, by itself, an architectural requirement.

What Copilot on the Report Canvas Does

Copilot works inside the existing Power BI authoring experience. You start with a semantic model and ask it to suggest content, create a report page, or add visuals. You can then ask it to change visual types or fields, delete visuals, and undo or redo recent Copilot actions. The result remains a native Power BI report.

Copilot report-canvas authoring works in both Power BI Desktop and the Power BI Service, subject to the documented requirements. In the Service, authors with the necessary permissions use Copilot from the report’s Edit view.

Microsoft documents the workflow in Create and edit Power BI reports with Copilot. You can also watch this report-canvas Copilot demonstration.

The important distinction is between what Copilot generates and what the Power BI authoring tools support. Microsoft’s documentation currently lists styling and formatting changes, custom visuals, and several semantic-model scenarios as limitations of Copilot report creation. That does not prevent an author from using the regular canvas tools to refine the report afterward.

The resulting report can use the established Power BI capabilities: measures, filters, slicers, drillthrough, bookmarks, visual interactions, themes, exports, subscriptions, and distribution. Copilot does not automatically configure all of these. It accelerates creation while leaving the author inside a reporting environment they already understand.

Copilot also supports narrative summaries. For the details, see Create a narrative visual with Copilot for Power BI. Microsoft’s overview of Copilot with reports and semantic models covers the broader author and consumer scenarios.

What Modern Report Builder Changes

Modern Report Builder introduces a different kind of deliverable. In Microsoft’s FabCon and SQLCon 2026 announcement, the user starts with a trusted semantic model, describes an application, previews and edits the generated experience, and publishes it to Fabric.

The intended result is a Fabric App: a data-driven web application that can combine analytics with user input, application data, and operational behavior. Microsoft describes scenarios that accept inputs, write data back, preserve shared state, and support workflows. These are capabilities to design and validate, not a promise that every generated application automatically implements them correctly.

The name needs some care. This is not the existing Power BI Report Builder for paginated reports. Likewise, a Fabric App in this discussion means a custom application, not a Power BI workspace app or org app used to package and distribute reports and other content. Apparently, Microsoft did not have enough product names already.

You can watch the Modern Report Builder demonstration to see the emerging authoring experience. Treat it as a demonstration of direction, rather than a guarantee that every feature shown is available in your tenant.

The Comparison That Matters

The comparison is not “basic charts versus better charts.” It is a choice between deliverables with different capabilities and responsibilities.

A Practical Example: Sales Reporting vs. Sales Operations

Suppose a management team wants to monitor revenue, margin, pipeline, and sales trends by region and product. Users need to filter results, drill into opportunities, export details, subscribe to updates, and share the report through their established Power BI environment.

I would start with a native Power BI report. Copilot can generate the initial pages and visuals, while the author configures the interactions, formatting, navigation, and distribution. There is little architectural benefit in rebuilding familiar reporting behavior in a custom application just because AI can generate the interface.

Now change the requirement. Salespeople need to review opportunities, update the next action, assign an owner, submit a discount request, and follow an approval process without leaving the experience.

That is an operational application with analytics inside it. The solution needs input validation, persistent application state, permissions for different actions, and integration with the systems that own those records. Modern Report Builder and Fabric Apps become more relevant as an architectural direction, although the complete workflow still needs to be designed and tested.

The charts may look similar in both examples. What users need to do after viewing them is what changes the architecture.

Where Rayfin Fits—and the Two Authoring Routes

Rayfin is the application foundation, not another report canvas. The Rayfin SDK overview describes the code-first foundation, while Fabric Apps provides the managed environment in Fabric. Together, they support application concerns such as data, APIs, authentication, access policies, business logic, and hosting.

Microsoft’s Rayfin product page and See Rayfin in action demonstration explain that underlying platform.

There are two complementary routes into this application model.

The developer route uses an AI coding agent with the Rayfin SDK and command-line interface. Developers work with an application project, define its behavior, test it, and deploy it to Fabric. Microsoft’s Create a Fabric App with the Rayfin CLI tutorial walks through project creation, local development, and deployment. You can also watch Microsoft’s Rayfin demo, which shows how GitHub Copilot works with Rayfin to generate an application’s backend.

The Power BI author route is the emerging Modern Report Builder experience announced for Power BI Desktop. In the demonstrated workflow, authors begin with a trusted semantic model, describe the application using natural language, and preview and refine it through a Power BI-friendly interface before publishing it to Microsoft Fabric, where users can access the resulting app through a browser. Microsoft also describes handing applications to developers and IT teams as requirements grow. You can watch Microsoft’s Modern Report Builder demo to see that authoring experience. Microsoft has not announced equivalent Modern Report Builder authoring in the Power BI Service; the demo illustrates a planned experience, not a guarantee of current availability in every tenant.

The shared foundation is important, but it does not make the authoring experiences interchangeable. A Rayfin development tutorial is not a tutorial for the Modern Report Builder interface, and an existing Power BI report does not automatically become a Fabric App.

Reporting Features Are Not Automatically App Features

One of the easiest mistakes is to assume that an application displaying familiar charts includes familiar Power BI behavior.

A custom chart is not automatically a native Power BI visual. Cross-filtering, highlighting, drillthrough, bookmarks, tooltips, export, subscriptions, and collaboration all deserve explicit consideration. Some behavior may come from the selected components or templates; other behavior may need to be implemented. The important point is not that every feature must be rebuilt, but that feature parity should be verified rather than assumed.

If users expect selecting one chart to filter five others, test it. If they rely on personal bookmarks, accessible keyboard navigation, or scheduled report delivery, put those requirements into the design and acceptance criteria. A visually convincing prototype is not proof that the complete reporting experience exists.

The reverse matters too. A Power BI report should not be forced into becoming an arbitrary application interface simply because the organization already has a semantic model.

My preference is to preserve the platform behavior users value and customize only where the business requirement earns that complexity.

Write-Back Does Not Mean Writing into the Semantic Model

Write-back is an important capability of Fabric Apps, but it is worth clarifying how it works, especially when the application uses a Power BI semantic model.

Microsoft’s Fabric Apps connector documentation distinguishes semantic-model queries from data-changing operations. The semantic-model connector executes queries; supported database connectors can expose create, update, and delete operations. Querying a semantic model does not, by itself, create a way to edit its underlying business records.

In the sales example, the application might read revenue and margin from the semantic model while saving a discount request to a SQL database in Fabric or sending an authorized update to an operational system. That is a design choice—not an automatic consequence of generating a chart and an input box.

I would decide where each change belongs, how it is validated, who can make it, and when the analytical view should reflect it. Those questions matter more than how quickly the form appeared.

There are also hybrid approaches that combine native Power BI reporting with application functionality, without requiring a standalone analytical application, such as a Fabric App built using Rayfin. The Power Apps visual allows users to interact with a Power Apps application directly inside a Power BI report, including entering or updating data. Alternatively, Power BI embedded analytics allows developers to incorporate native Power BI reports into a custom application without recreating the reporting functionality. These hybrid approaches can preserve existing Power BI capabilities while adding application-specific features, although they have their own licensing, security, and integration considerations.

For a report that needs a modest amount of operational interaction, I would evaluate those options before replacing the reporting experience. For an application with extensive navigation, state, and workflow requirements, the balance may favor an application-first design.

More Freedom Means More Ownership

A native report still requires care. Someone must validate the measures, relationships, filters, security, and interpretation of the results. Copilot can create a first version faster; it cannot decide whether the business definition of “margin” is the right one.

A custom application adds another set of questions. What happens when two people edit the same record? Can a user submit an invalid value? Who can approve a request? What happens when a backend operation fails? How will the team test, deploy, monitor, and support changes?

Fabric provides managed services and security controls, but the application’s own behavior still needs review. Authentication establishes who signed in; it does not, by itself, establish that every action the interface exposes is appropriate for that person. Microsoft’s Fabric Apps documentation explicitly separates platform-provided security protections from application-owner responsibilities.

My recommendation is to decide who owns the application before treating the prototype as a production solution. That owner does not have to write every line of code, but the team needs the skills and processes to evaluate what the AI produced. Unfortunately, the prompt does not volunteer for the support rotation.

Availability and Licensing: Keep the Experiences Separate

There are three different things to track: report-canvas Copilot, the Fabric Apps platform, and the Modern Report Builder authoring experience. Their availability and licensing should not be treated as interchangeable.

Report-canvas Copilot has a documented workflow and prerequisites. Microsoft’s Copilot requirements include eligible organizational capacity, tenant settings, regional support, and appropriate permissions. A Power BI Pro or Premium Per User license alone is not sufficient for the existing Copilot experience.

Fabric Apps and Rayfin have a documented developer workflow, with Fabric Apps labeled as preview. The current Fabric Apps overview lists an assigned Fabric capacity and tenant enablement among its prerequisites, with regional availability restrictions. Being able to build through the Rayfin CLI does not establish that the Modern Report Builder interface is enabled.

Modern Report Builder’s Power BI Desktop experience is described as forthcoming in Microsoft’s Power BI agentic app creation announcement. Microsoft also announced preview access for Power BI Pro, Premium Per User, and Fabric capacity customers. Its FabCon announcement describes Fabric Apps and Fabric Database capabilities, including up to 1 GB per app, at no additional cost for the announced Pro and PPU scenarios.

That announced access model is significant, but it should not be substituted for the current prerequisites of a different experience. Before planning production use, confirm the rollout, supported features, licensing, and limits that apply to the specific path you intend to use.

A preview platform, a demonstrated authoring interface, and an announced licensing model are related. They are not the same thing.

Additional Resources and Demos

For more background on the application platform, Microsoft’s Rayfin announcement and embedded video explain the motivation and architecture behind its managed backend.

The Fabric Apps gallery provides examples to explore. These illustrate the broader application direction; they should not all be interpreted as demonstrations of Modern Report Builder itself.

Final Thoughts

The best choice begins with a simple question: are you building a report, an application, or a combination of the two?

I would not build a custom application merely because it offers a different-looking dashboard. I would build one when the required actions, state, navigation, and workflows justify it. Just as importantly, I would not force a report to become an application when the requirements have clearly moved beyond reporting.

AI makes it much faster to create the first version. It does not eliminate the need to choose the right architecture. Because that first version can now appear so quickly, making the choice early has become even more important.

In my next post, I’ll explore how AI can help build semantic models, ontologies, and Fabric Data Agents. We’ll follow a sales analytics example to see how these capabilities complement one another and where human judgment still matters. Creating an experience faster is useful. Making sure everyone agrees on what its numbers mean is essential.

More info:

Is Power BI Reporting Dead? (What AI Changes for Power BI) (video)

The post Copilot on the Power BI Report Canvas vs. Modern Report Builder first appeared on James Serra's Blog.