This article originally appears on the AvePoint blog as When a List Isn’t Enough: A Case for Dataverse and Model-Driven Apps.
I like working with Microsoft Lists. They’re easy to create and easy to populate and have many options to improve the user experience with features like column formatting and extending functionality using services like the Power Platform.
However, there are situations where a list is not the right choice for data storage. Simple data relationships can be implemented in a list using Lookup columns, but highly complex relationships (many-to-many) are challenging to implement. Out-the-box security options in Lists are limited to the item creator or anyone with access. Implementing complex security models where — for example — Department “A” can view all items created by Department “A” members is not possible.
Many look to Azure SQL Database or Dataverse in these situations. Both are excellent platforms that are performant, secure, and scalable, but they require a front-end investment that many non-developers are unwilling to make. In the case of Dataverse, the most logical front-end comes in the form of PowerApps as a custom Canvas app or an out-of-the-box Model-Driven app.
Canvas vs. Model-Driven Apps
As the name implies, Canvas apps provide you with a blank canvas to develop a customized interface for your users to interact with.
Model-Driven apps provide a consistent user experience to interact with your data by allowing you to create lists, forms, charts, and reports using your data model. You automatically get functionality that you would otherwise have to write from the ground up in a Canvas app (like search, sort, filtering, business logic, business rule enforcement, exporting to Excel, document generation, etc.), allowing you to interact with your data much quicker.
The trade-off is that you get ready-to-use functionality but lose the ability to create pixel-perfect apps like you’d have with Canvas.
I suppose this is one of the reasons why I like Microsoft Lists as much as I do; I can focus on implementing a structure that reflects the business process at hand without getting bogged down in front-end development.
Another benefit of using Dataverse is gaining access to the Common Data Model, a collection of predefined schemas (tables, attributes, metadata, and relationships) representing commonly used objects like Accounts and Contacts. This à la carte approach to data modelling reduces our time-to-value. It also introduces a higher degree of reusability into our solutions through common entities (tables) and data.
I have many solutions in my professional life that have outgrown Microsoft Lists and are moving to Dataverse and Model-Driven apps to meet those needs. My approach to these moves is to find overlap in the list columns and data better suited to become a common entity. For example, I have customer information across many of the lists. Merging the customer data into a single entity means only having to reference and maintain a single source of truth.
The next step is to determine if an existing entity in the Common Data Model will meet my requirements for storing the customer data. The Account entity has the majority of the columns that I need while allowing me to add any necessary business-specific columns. The Account entity, like all Common Data Model entities, includes all of the forms and views I need to kick start my application front-end with only configuring the forms and views to suit my user’s needs.
Once the overlapping data is centralized and other Common Data Model entities are found, we will create custom entities to support the tracking of our business processes. It’s very important that we set up the correct table relationships to support business processes as we build our new entities. In many cases, we’ll connect our custom entities (for process tracking) to our Common Data Model entities — like Account.
Finally, I’ll also use the data import options like Edit data in Excel and Dataflows to migrate my data into my new database and add Power Automate to automate all the mundane tasks that I can.
As I stated earlier, there are situations where Microsoft Lists are not the right choice for a solution. Dataverse, coupled with Model-Driven apps, is a great way to develop a data model that reflects the needs of an organization’s current and future business processes. By sharing my approach to moving from Lists to Dataverse, hopefully, I was able to supply a reference point and perhaps validate others considering the same move. Thanks for reading, and special thanks to Hugo Bernier at Microsoft for his help on this post.
Thanks for reading!
2 thoughts on “When a List Isn’t Enough: A Case for Dataverse and Model-Driven Apps”
Thanks Norm. This topic is one where it would be interesting/helpful to explore some specifc use cases, and what business need, degree of required scale, security need, or other factor – licensing for example – might lead to a Lists, Dataverse, Dataverse for Teams, and/or Azure Storage technology idea-use case, with a mid-level dive on why, etc.
I understand this could be complex, and perhaps beyond the intended scope of your blog.
However, since Microsoft’s value proposition, more and more, is related to scenarios that run across Azure, M365, the Power Platform, and D365, and even within the Microsoft community, individuals tend to identify as “M365,” Power Platform/D365, or Azure, rarely all of the above, this seems like an area with more to it (potenntially)
Thanks for reading and for the thoughtful question. I agree with you and feel that there is value in sharing the scenarios and decision-making to using one platform vs another. I think will make for an interesting, albeit one-sided, set of blog posts. I say one-sided because others will have a different perspective on the same situation/scenario.
It would be so valuable to have multiple authors present their views on the same scenario and how they would approach it. Hmm… the gears are churning in my mind right now.