Why would you use Dataverse, if SharePoint lists gives you the option to avoid premium licences?

Dataverse or SharePoint lists?

Dataverse or SharePoint lists, that is the question.

There are a few things we have to consider when we try to answer the question.

• Data Volume
• Security
• Delegation
• Licence Cost
• Simplicity
• Development time
• Maintainability
• Connectors/APIs

Data volume

SharePoint is a great option if you want to store your data into simple lists and the data volume is small. Larger amounts of data in your list isn’t immediately a problem, but you might have to be a little cleverer in the way you build your apps and flows.

For larger solution you should quite often consider a database you could of course consider SQL server, however that quite quickly requires a DBA to be available. Adding new fields/columns becomes something that is quite a bit harder than in SharePoint.

one option that might then work is Dataverse. Dataverse is the data platform that comes with the Power Platform that doesn’t require a DBA. A Dataverse Administrator might be something that could help though.

Security

Especially if you want to secure items at an item level rather than a list level, you might find that you hit some limitations. Once you have too many items with unique permissions you will hit all sorts of difficult problems to solve.

Also, setting permissions in SharePoint form a Power App or a flow is not always the easiest thing to do.

Securing items within Dataverse is a bit better and isn’t as limited as in SharePoint.

another important point to consider is that items and documents in SharePoint can be referenced using a URL. So where you might think that hiding data from Search and making sure that users don’t know where your lists are is sufficient. If a user doesn’t get hold of a url to an item, they could potentially find the data held by other list items.

Comparing this to Dataverse, you will find that there isn’t a url that references a record in a table.

Delegation

Delegation is the option to send queries to your data source. These queries then get resolved within the data source before the results are returned. In my post about Delegation a while back, I mentioned the available options for SharePoint connections.

Delegation in SharePoint is slightly limited if you compare it to SQL server as I mentioned in my post a while back. So once again the volume of data can be something that is important to consider.

This simply means that your app or flow might have to do a bit more of the hard work.

Licence Cost

Absolutely none, well, that is you are already paying for it. To access SharePoint lists form the apps or flows doesn’t cost you anything extra.

Quite often this is the reason for people to choose SharePoint. But is that really right? Well, it all depends.

Simplicity

The creation of SharePoint list is definitely easier than the creation of Tables in Dataverse. That is of course if you are a user who is already used to using SharePoint lists.

No need to worry about solutions and no worries about complicated relationships. But when you really start to think about it, SharePoint lists can be copied from one site to another (e.g. using PnP PowerShell). And when you use lookups you can also have something that feels a bit like Relationships in Dataverse.

Development Time

Development time can be one of those hidden costs. If I assume for one moment that you are familiar with both SharePoint and Dataverse then the creation of Tables and lists is fairly similar. But what if you are familiar with one or the other? It might be quicker to develop lists or Tables in you personally preferred option.

Maintainability

When I have multiple environments and multiple SharePoint sites with identical lists. Using PnP PowerShell I can very quickly keep my different sites synchronized as I add new fields to my development version of the site. However I can’t easily bundle my data model and my apps in a single file. Yes, I sometimes do miss the good bits of the .wsp files that we used to have in SharePoint.

Connectors and APIs

When I compare the connectors for Dataverse and SharePoint. There is one very important factor

In SharePoint you can make 600 calls per minute to the connector, while in Dataverse you have 6000 in 5 minutes.

But there is more to consider within the connector.

Dataverse currently has 13 actions and 2 triggers in Power Automate

While SharePoint has a lot more. Especially the Send an HTTP request to SharePoint is useful when you want to use the API to do something that isn’t supported directly within the connector.

Maybe soon we will get an action to call the Dataverse Web API within the connector.

New in Dataverse!

This is a buit of a bonus at the end of this post. Last night the Common Data Service connector was finally to Dataverse.

Have you noticed the new icon?

So, which one wins Dataverse or SharePoint?

I would still say it all depends. For smaller solutions that will not grow (Do you still remember floppy disks and hard drives of 20MB that you would never fill?) you could use SharePoint. Also if your organisation is just getting started with Power Apps, then SharePoint might be a good option for a proof of concept project.

Unfortunately I still see licence cost, being the only thing that is considered. It’s a bit like getting a pack of paper and a pen to write a book, because that is cheaper than a laptop.

But for the more serious solutions that you might want to build I would consider using Dataverse instead.

Find more great Power Platform blogs on Power Platform Week.

About the Author

Since 2007 I’ve worked with SharePoint as a Consultant, Developer and Architect. I work at Hybrit Services  in Weedon Bec, United Kingdom as a SharePoint Consultant.

Reference

Veenstra, P., 2021, 8 top reasons to use Dataverse or SharePoint lists in the Power Platform, Available at: 8 top reasons to use Dataverse or SharePoint lists in the Power Platform (sharepains.com) [Accessed on 11 January 2023]