Let’s talk about data sources. Model-driven apps are restricted to using Dataverse only, whereas canvas apps can read from a large range of data sources, even multiple data sources within the same app.

This is a big advantage that canvas apps have over model-driven apps, no doubt about it. However, you should ask yourself the question if the data can be migrated into Dataverse or not.

Let’s imagine the scenario where you are replacing a legacy .NET application with a new Power App. The legacy application reads from an Access database. You could create a canvas app that uses the same Access database.

Alternatively, you could follow our previous series of posts and migrate the data from Access into Dataverse. This would give you the option of using either canvas or model-driven apps instead of being restricted to canvas only.

However, you must consider if there are any other applications that are using the Access dataset – either you upgrade those as well, or you stick with the canvas app approach. In this way, canvas apps are the least destructive way of integrating into existing data architecture. That said, they will require more effort to build in comparsion with the model-driven app.

What about the user interface? It’s an often toted fact that canvas apps give the developer more control over the look and feel of an application, customising the appearance to their heart’s desire. Surely that’s a good thing, no?

In the words of Peter Parker’s uncle Ben – With great power comes great responsibility.

Yes, we can style and theme canvas apps to a much greater degree than we can with model-driven apps. They can colourful; we can place buttons, images and form controls anywhere we like on the canvas; we can mix and match fonts.

However, there are many user interface components that are not available out of the box and developing a canvas app can involve a certain amount of “reinventing the wheel”.

For instance, at the time of writing canvas apps have no native tab control like you have with tabbed forms from a model-driven app. Sure, there are plenty of articles online as to how you can create tab-like functionality with custom code, but now the developer has more responsibility for managing the interface than they had before.

Furthermore, canvas apps do not natively implement pagination and filtering. This is a big deal when working with large datasets. A model-driven app View will only fetch X number of records from Dataverse at a time, where X is the maximum number of records you wish to display per page. This also takes into account any filters that have been applied (e.g. show only those records created in the last week by a specific user), as well as and sorting you wish to apply.

By contrast, canvas apps will attempt to load in all records of a dataset (within memory limitations), which severely impacts overall performance of the app if you have a large and/or poorly optimised dataset. Many developers use the native Filter and Sort functions within canvas apps – whilst this does return the required results, the app itself still maintains all unfiltered records in memory.

The correct way to handle this scenario would be to use Power Automate flows to fetch X number of records taking into account filter and sort criteria (this is known as delegation). But once again, the developer has much more responsibility for the user interface than they do with model-driven apps, where this specific functionality is available out of the box with no further developer input required.

It’s often said that with canvas apps it is possible to tailor the look and feel of the app to match customer branding. This is true, but arguably external branding is more important than internal branding – a company website is carefully curated and branded as it is externally facing, but would they take the time and effort to rebrand their internally facing software? Outlook? Word? Excel? Teams? All of these internally facing tools are branded in the supplier image, not that of the consumer. Ask yourself if the need to style your app to match a customer brand is really a need or a very strong nice to have before committing to a tech choice.

Pages: 1 2 3