In this next post in my series on solution architecture for the Power Platform, we’ll continue to look at the topic of designing data models and designs for solutions we’re implementing for customers on the Power Platform, but in this post, we’ll focus on the features and functionality that exists within Dataverse and talk about designing data models specifically that work with Dataverse and that utilise its functionality in the most appropriate way.
Recap…
Okay friends, so before we continue, make sure you’ve read these previous posts in the series to ensure you’ve got the background context to what we’re talking about here!
Okay friends, now you’ve caught up let’s jump into the things we should be considering when designing data models and architectures for Dataverse!
Table types in Dataverse
When working with more traditional databases and custom development you might be more familiar with having to develop all of the functionality yourself. In Dataverse we have pre-existing low-code functionality which includes different table types when we create tables…
So friends, when creating data model designs and architectures for Dataverse, remember the ability to utilise the following types of tables…
| Standard | Standard tables for you to store the data you need to in directly in Dataverse. |
| Activity | These tables are used to store interactions such as phone calls, tasks, and appointments. A set of activity tables are in a Dataverse database. |
| Virtual | These tables allow you to create the table and columns in Dataverse but then use an external data source to store the data. To the user, the data appears in their apps like any other data. |
| Elastic | Designed to handle large volumes of data in real-time. With elastic tables, you can import, store, and analyze large volumes of data without scalability, latency, or performance issues. |
Ownership type
When we create data in Dataverse there’s two types of ownership for that data which we set at the table level which then determines how the data in the table will be owned.
- User/Team – The default and for users or teams to own data only.
- Organization – Used for reference data by anyone in the organisation.
Global choices
In Dataverse we have the capability to create a set of choices and then use that set of values for multiple choice columns across multiple tables. If we were to then update the global choice, the changes would get reflected everywhere we’ve used that global choice across all relevant tables and columns.
We can also create column specific choice values which don’t synchronise in this way but it’s important to be aware of both choices and to choose the correct one as appropriate.
Options for file and image data
- File and image columns for one file / image uploads
- SharePoint integration for Dataverse – There are permissions issues with this and SharePoint permissions do not sync with Dataverse row permissions creating difficulties for security architectures.
- Azure Storage – Archival and external access
What’s coming up?
So friends, these were just a few of things you should consider when implementing data solutions using Dataverse for your wider Power Platform solutions. There’s a whole lot more so do not use this blog post as your only tool to figuring out what you should be considering when designing for Dataverse. As solution architects for the Power Platform, we should be very familiar with Dataverse and its features and functionality. In the next post, we’ll look at some best practices in this area. Stay tuned! 🤩