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 modeling 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.
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.