Microsoft Dataverse

8 top reasons to use Dataverse or SharePoint lists in the Power Platform

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 😉


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


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.


Personally I like the idea of solutions in the Power Platform and I can’t wait for connections to be properly included in the solution deployment story.

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.

Pieter Veenstra

Business Applications and Office Apps & Services Microsoft MVP working as a Microsoft Productivity Principal Consultant at HybrIT Services. You can contact me using

View Comments

  • Because SharePoint is not a relational database. I have seen so many developers base their design decisions on this false choice only to pay much more later when their SharePoint app is falling over because of the number of relationships they are managing in code, the volume of data in the various SharePoint lists, the number of app users and the amount of data being read, written, updated. When that SharePoint Enterprise app is failing at the wrong time and users are complaining, and failures are getting escalated so that now leaders multiple levels above you are aware of the poor decisions made, will you be able to defend those decisions?

    If you are making a website or collaboration space or document management app, SharePoint is the tool. If you are building apps that will rely on a relational model, or apps that will create and use more than a few hundred rows of data, Dataverse or other relational datastore is the right choice.

    The decision to choose SharePoint because it avoided a Power Apps license is a false choice. Bad architecture has a cost. Maintenance of bad design has a cost. Fine if your management will not approve the Power Apps license. Make sure your analysis and recommendations to them includes the cost of the technical debt you are creating as a result of a poor design decision.

Recent Posts

1 step to update an item in an array in Power Automate

What do you do when you have an array of data in Power Automate and…

1 week ago

Failed to load in Azure Synapse Workspace

After last week's post about how to configure Azure Synapse Link to export data from…

1 week ago

Buckinghamshire & Northamptonshire Power Platform User Group launch

Have you been waiting for a new face to face Power Platform User Group in…

1 week ago

Configure Dataverse exports using Azure Synapse Links for Azure SQL Databases

In this post I'm looking at the Azure SQL databases option that is part of…

2 weeks ago

5 steps to implement word based search in Power Apps

A common requirement in Power Apps is to create a word based search on data…

3 weeks ago

900th post on, it is a time to celebrate and win!

This is the 900th post on and I thought this would be a good…

1 month ago