There’s more than one way to make a bed. If you’ve ever searched for applications as a solution to a business problem, you know there’s also more than one software option to solve a problem. Hopefully by the time you’re reading this, you’ve already identified Microsoft’s Power Platform — and specifically Power Apps — as the solution you want to use to solve problems in your business.
One of the first things you learn in the Power Apps space is that there are two “ways to make a bed” here too: model-driven and canvas.
All too often, when people think about solving problems with Power Apps, the only solution they consider is canvas apps. In this blog we’ll cover the similarities between the two solutions. Most importantly, we’ll highlight features and differences for each app type so that you can make a better informed decision on which type you want to use for a specific problem.
Microsoft Power Apps similarities
- Whether you choose a canvas app or a model-driven app, they use the same cost/licensing model.
- They can both access data in the Common Data Service.
- They can both be managed and deployed using solutions within the Power Platform.
- Both have responsive design, which allows them to work on mobile, tablet, and desktop devices.
- When using Common Data Service data, both use the same robust security model to interact with the data stored there.
Now that we’ve noted the similarities, let’s review each application.
What are Power Platform canvas apps?
Microsoft made a great selection when they chose the word “canvas” here. The development for this type of Power App is very similar to the blank canvas that an artist uses to paint a masterpiece. From the get-go, the development of a canvas app starts with a blank screen (as shown below) where you can drag and drop components that you build into an app bit by bit.
Business logic is implemented in all canvas apps using a formula language (like Excel formulas) inside of component attributes:
What do canvas apps do well?
Since you start from a blank canvas, the experience you design can be highly tailored. Place buttons, icons, fields, etc. anywhere you like. There’s a wide variety of different components from which to select.
Coming from a Microsoft Dynamics CE/CRM background, I think one of the toughest requirements to solve is giving users a way to update multiple records of different types in a single screen. Before canvas apps were created, this problem called for custom development. Canvas apps easily solve this problem with little to no code.
Accessing data can be equally as trying as writing code for the UI in a custom application. Canvas apps provide a wide range of different data connectors that allow non-developers to get and create data from many different sources. CDS, SQL, and Microsoft 365 are just a few of the sources to which you can connect with pre-built connectors. See the full list here.
What can’t canvas apps do?
Canvas apps’ biggest strength are also their biggest weakness. The power to design from scratch means you need to build every piece of functionality. Many times, apps are used for simple processes where users need to create or update records that are stored in a system and then be able to see all similar records. This should be a simple business case, but development is still needed with canvas apps. Model-driven apps do a better job at handling these repeatable processes.
Be careful when you’re designing a canvas app that the requirements of the app don’t get too complex. As complexity increases, it gets harder to manage the app since the logic for it is stored across many different components, which can make it hard to pin down bugs in the app.
Canvas apps are flashier than model-driven apps. This is not a shortcoming of the product itself. However, this does often lead to people choosing a canvas app without considering the requirements at hand.
What are Power Platform model-driven apps?
Model cars come to mind when I think of what the development experience is like in model-driven apps. A model comes in a box with all its pieces and the instructions to put them together. Model-driven apps use many pre-built components, along with data in the Common Data Service, to provide a streamlined app-creation process.
Business logic in model-driven apps can be handled with either Business Rules (drag-and-drop configurable) or client-side JavaScript.
What do model-driven Power Apps do well?
Model-driven apps handle common actions that users perform when interacting with data right out of the gate. Want to save a record? There’s no need to write any code (or even use formulas for that matter). Out-of-the-box save buttons come on every form. Do your users need to see a list of data and apply filtering to that list? It’s all taken care of with “grid views” and filtering right out of the box.
Check out Microsoft’s documentation for more details and features.
What can’t model-driven Power Apps do?
The biggest shortcoming for model-driven apps is the inability to interact with data sources other than the Common Data Service. If you need to see data in a model-driven app, it must reside in CDS or be connected to CDS via virtual entities, which require custom development to use.
Business requirements to update multiple different record types are a common occurrence today. One such example is when a user needs to update a contact’s phone number while creating a new lead in the system. Within a model-driven app, there’s no easy way to do this without storing that phone number within the lead and then having some automation go back to update the contact with the new information. If you need to update multiple records from different entities, model-driven apps are not your best option.
We hope this gives you a clearer picture of the two different types of Microsoft Power Apps. Stay tuned for our upcoming Power “Inception” blog series, where we will cover using parts of the Power Platform inside one another.
Need help designing or building a Power App? Reach out to us today at 763-412-4300 or fill out our contact us form.
