Best practices and recommendations for building model-driven apps in Power Platform
Microsoft Power Platform has opened up the floor for citizen developers to improve efficiency, optimisation and automation. Just one way your people can do this is by using model-driven apps, which can help you solve complex, data-dense problems.
In this blog, the third in a four-part series, Solutions Architect Steve Worrell highlights the best practices and recommendations when creating model-driven apps in Power Platform.
What are model-driven Power Apps?
Model-driven apps give citizen developers the ability to build components simply using data from the Microsoft Dataverse, a cloud-based database for your business applications.
You can use Dataverse to create forms, views, charts and dashboards, then bring these into your model-driven app via the in-built app editor.
When to use a model-driven app
Model-driven apps are most suited to processes that require organisational data to be stored in a database, such as asset tracking, case management, customer relationship management and event management.
Crucially, model-driven apps are built upon Microsoft Dataverse, a customisable database, in which users can add their own tables or use those provided. The model-driven app user interface (UI) can then display the business data from the tables created.
You’ll need a Power Platform environment with a Dataverse database deployed to build a model-driven app.
A model-driven app comprises data, UI and logic components, granular level security, and the ability to integrate with other Power Platform apps and extend with code. Read on below to find out about the features, best practices and recommendations for those beginning their model-driven app building journey.
Getting your data model right
The first step in creating a model-driven app should always be to define your data model. This involves planning and designing the tables and columns you will need in Dataverse and the relationships needed between those tables.
Several standard and activity tables are provided out of the box in Dataverse. It’s therefore recommended you review these in order to verify if they meet your data model requirements. If not, custom tables can be created.
Users are not limited by the number of columns they can add to a table but keeping columns to a minimum and using descriptive naming is advised.
There are three types of relationship that can be created between tables: one-to-many (1:n), many-to-one (n:1) and many-to-many (n:n). A table can employ single or multiple relationships with any other table.
Advanced relationship options are also provided if you want to add cascading behaviours to your related tables.
Working with the app’s visual display
As touched upon in the first blog of this series, customisation of the app interface is limited, principally focused on display and navigation of data on screen. The lack of design flexibility does, however, have its positives in that the learning curve for builders is gentle and implementation fast.
Columns from Dataverse can be displayed in the app UI via forms and views.
Forms in model-driven apps
Each form is associated with a table, the columns of which can be added or removed from a forms display, with the purpose of the form to submit data. Multiple sections can be added to a form layout and columns can be transitioned between them. You can ensure your form layout display makes sense by grouping related columns together.
Most powerfully, other table records can be integrated into your forms and displayed in views via a component called a subgrid. This is incredibly useful when interrogating related data, such as viewing all purchases from a specific customer or all tickets raised for a specific user.
Views in model-driven apps
Views provide an overview of data submitted to a table. Like forms, the columns displayed can be customised and multiple views can be created for a table. Filters, sorting, search and other configurations are also possible. Unlike forms, views are read-only and not for data entry.
A system chart, or multiple system charts contained within a dashboard, can also be exhibited on the app. Individual charts can be added to table forms and dashboards can be added as links to the site map.
The site map or navigation will always sit on the left-hand side of the app interface and can be used to add access to tables, custom pages or dashboards.
Lastly, custom pages can be displayed within a model-driven app. These are canvas apps which are integrated as single pages. This gives you a more flexible layout and display and incorporates the benefits and tools within a canvas app inside your model-driven app. For more on canvas apps, take a look at my previous blog.
Applying business logic to your model-driven Power Apps
You can apply logic to your data using four main components: business process flows, business rules, Power Automate and background workflows. Each of these provide unique functionality and it’s not uncommon to use all four within a single model-driven app.
Business process flows ensure a strict set of steps are consistently followed when a user is submitting data into the app. Using the example of a case management-based app, a business process flow could be added to make sure users always pass the same stages as a case progresses, keeping the process standardised for all users and cases.
Business rules provide invaluable server-side business logic to forms in a model-driven app. With a business rule, columns can be shown or hidden, enabled or disabled; column values can be set or cleared, made mandatory and validated.
Power Automate is a separate app within Power Platform but it provides a native integration through its many Dataverse triggers. With Power Automate, it’s possible to create automations with the countless options provided, such as updating related tables, approvals or sending notifications to specific users. Power Automate flows come in three flavours: automated, instant and scheduled.
Background workflows also provide automation but unlike Power Automate, no UI is provided. Although most of the functionality offered by background workflows has now been superseded by Power Automate, there are a few useful features still available that aren’t in Power Automate, such as wait conditions for columns.
How you can secure your model-driven apps
Dataverse provides a complex set of security features allowing system admins to implement a model that best suits each business process use case. I’ll introduce some of the key security elements below, but it’s far too detailed a topic to do justice to in a short overview. For detailed documentation, take a look at this article on Microsoft Learn.
Security roles underpin security access across not only Dataverse but also the entire Power Platform environment. A security role is a level of access granted to the individual users assigned that role. Users can be added to multiple security roles.
The central tenet to Dataverse security is that all access granted to a user via security roles is cumulative; a user has access to every privilege each role provides, even if one security role overrules another, with the highest privilege recognised.
Privilege levels include Create, Read, Write, Delete, Append, Append To, Assign and Share across an access range of Organisation, Business Unit and User, all of which means there is huge scope for granularity and deep specificity for table records access and editing.
Teams (not to be confused with Microsoft Teams) are also a useful feature of security. A team, or more accurately a selected group of users, can be created, given a relevant team name and then be assigned security roles, making it easier to manage access from an admin perspective and also allowing logical groupings of users. You can create Teams in the security settings.
Where discretion is needed for specific columns, it is possible to create column-level security, restricting the ability for users to see data in a specific column. Columns that have this enabled require a column security profile which can then be assigned to individual users or a team. This scenario is particularly useful for records holding personal information or financial records.
Integration and extensibility of model-driven Power Apps
Model-driven apps can be integrated with all other apps within the Power Platform. As well as harnessing Canvas apps and Power Automate integration, you can build Power BI reports and dashboards using Dataverse as the data source and presented within the app.
External data can be brought in to Dataverse using virtual tables, meaning third-party application data can be assimilated and interrogated in an app.
That brings to a close our walk-through of the key features of model-driven apps and the logical build steps from data through to security. While we’ve covered a lot, this is just scratching the surface of the possibilities available with model-driven apps, Dataverse and their integrations with Power Platform.
Look out for the final blog in this series coming next week, providing an in-depth overview of the best practices when implementing Microsoft Power Pages.