Why bother about Dataverse and Model-Driven App?

Introduction

Recently someone on Reddit asked what are the main benefits of Dataverse and Model-Driven App compared to SharePoint. At first the question may seems strange since those two platforms serve different purposes: one is a Low-Code platform while the other is an Enterprise Document Management System.

Although that is true, SharePoint can also be considered as a No-Code development platform especially when combined with Power Automate, Canvas App and other M365 products. Apps built with those technologies are sometimes referred as “Mashup solutions” since they require the use of multiple products and technologies to support a business process.

Thus, if SharePoint is considered as a No-Code platform it is fair to compare it to Model-Driven App (I’ll use the acronym MDA for the rest of the post) and Dataverse. That user on Reddit noticed that creating a table with MDA involves a lot more work than creating a SharePoint list and he was wondering why we should invest time creating Model-Driven Apps.

I gave my thoughts on Reddit but here is a more complete version that may help you understand the benefits of MDA if you’re not familiar with that technology.

The main benefits of Model-Driven App and Dataverse over building an App with SharePoint

Dataverse is a relational database

This point is one of the most important in my opinion but is also the more abstract one especially for non IT folks.

The database used when creating a MDA is called Dataverse. It is actually a regular SQL Database with a standard model already provisioned when you create a new environment. That model is composed of tables that represent common business entities (accounts, contacts, users, etc.).

Thus, when creating a new custom table in Dataverse an actual SQL table is created. Same when adding a field to a table, a SQL column will be added to underlying SQL table. It may seem obvious but that is not the case with SharePoint. Of course SharePoint data is stored in a SQL database but the actual database schema is not paired to the lists and libraries. There is a good reason for that: SharePoint is designed to handle unstructured data (documents in that case).

At the end of the day using a relational database and model is best when developing an app. For example although you can put millions of items in a SharePoint list you should not exceed 5000 items in a single view. There is no such limitation with Dataverse. You also get way more options with Dataverse and MDA when querying data either when using the web interface of through the API (it is way closer of what you would get in SQL).

Relationship Management

Although the previous point is very technical, this one is very business oriented. MDA is made to handle complex relationships. You can easily model 1:N and N:N relationships and display those in any form.

The platform is made to allow navigation through linked records so you can drill down the relationships.

The only thing SharePoint provides is lookup columns but they are way more limited than what you can configure in MDA. In a MDA form you can for example filter items to display in a lookup either based on a view or even based on a dynamic value in the form (cascading lookup). You can even allow the user to switch between available views.

As soon as you start creating an app than contains multiple tables with relationships you start realizing that SharePoint as never been designed to handle such scenarios and you should really consider MDA and Dataverse.

Business Processes Modeling

Let’s be clear, saying that you can model a complex business process with Model-Driven App is in my opinion a bit of an overstatement. Nonetheless you can at least visually represent the stages of a business process and it is easy to follow the progression of your processes in a MDA thanks to what is called Business Process Flows. You can even add some basic branching in a BPF.

With SharePoint what you could do is create a choice column to represent the stages of the process but you would miss a lot of features or at least it would be way more complex to implement the following MDA features:

• Branching: based on some custom conditions you can skip some stages for example.
• Multiple processes for the same table: you can configure multiple BPFs for the same table and the right process can either be selected manually or automatically.
• Multiple instances of a process for the same record: you can keep track of multiple process instances for a single record. It is also possible to abort and reactivate a process instance.
• Process duration: by default a process instance duration is tracked and displayed for each instance.
• Requiring that certain fields are filled up per stage. This is a very powerful feature that allows users to save a record without entering all the information while making sure the required information is entered when moving to a specific stage.

Form Customization

The ability to customize the layout of a form is a strong selling point of MDA. It is true you are limited in term of modifying the look and feel of the platform but you can very easily and quickly create tabs, sections and group fields to ease the data entry.

In addition to that you can also create custom components (PCF) to customize the way a field is displayed on a form.

Until recently it was impossible to customize a SharePoint form without a lot of custom development. Now two options are available:

• JSON can be used to edit a form layout. You can create a header, footer and regroup fields in sections. Unfortunately there is no GUI (yet) to ease the configuration and the options are very limited.
• Canvas App can replace a SharePoint form. The main drawback is the effort needed when most of the time you only need to rearrange fields and group them in sections and tabs.

Even though SharePoint starts providing features to customize the layout of a form it is way more limited than MDA while being more complex. That is especially true since Microsoft has deployed the latest version of the designer used to edit MDA forms that provides a WYSIWYG experience. You can very easily edit a form in front of the user which is useful when prototyping applications.

Views

MDA views are a very powerful tool. You can create quite complex filters in a MDA. It is not as advanced as what you can do in pure SQL of course but you can group conditions together (and choose between OR and AND operators) and lot of conditional operators are also available including some specific to date and user field types (filtering on the current day, tomorrow, yesterday, current month, current quarter, current fiscal year, current user, current user’s team and so on).

Another big difference with SharePoint is the ability to filter on related records. You can apply all those operators to any field of a related record or even on a related record of a related record (I guess there must be a filter depth limit but I never had a case where I hit it).

Last thing I like in MDA is the ability for users to create their private views (as they also would in SharePoint) and share those to the users of their choice (not available in SharePoint this time).

Implementing custom business logic

Dataverse and MDA offer multiple ways of adding business logic into an application:

• Business rules can be used to add simple business logic to forms and/or tables. You can hide/show fields or sections depending of the value of a field for example. Available actions are limited but those rules are easily configurable through a GUI.
• Even though Classic Workflows will certainly be replaced by Power Automate they are still very useful to implement server-side validation either asynchronously or synchronously. One use-case I face very often is the addition of business rules that must prevent a user of creating or updating a record if some conditions are not met. This can be implemented very quickly with Classic Workflows and will apply even if the record is modified through the API or an Excel import.
• Power Automate is also an option to add business logic but unfortunately you are limited to asynchronous execution and that prevents adding logic to block a record from being created, updated or deleted. It is nonetheless the go to option when you need to add automation to your solution.
• JavaScript can be injected into a form. Specific Client-Side APIs are available to implement complex business logic. This enables you to develop very complex validations while being fully supported by Microsoft.
• Plugins can be developed to implement complex business logic. The SDK provides a lot of events that can be registered to execute your code. You can even execute code when the model of your application is modified enabling you to implement complex automation when a table or column or security role are added for example. Plugins can also be configured to run either synchronously or asynchronously and they can prevent an event from happening which is very useful to block an action depending on custom logic.

In comparison SharePoint does not offer much to implement business logic. Of course you can set some validation on the fields (as you can do in Dataverse) but even something as simple as displaying fields or sections depending on conditions will require the use of Canvas App and that costs a lot of time. You also can develop custom Event Receivers but that is as complex as developing Dataverse Plugins.

Bulk editing and deleting

Aside from the editable grid available in SharePoint there is not much you can do if you need to import or edit a high volume of data.

Fortunately Dataverse and MDA provide multiple ways of doing such things. First you can use the editable grid to make quick adjustments.

Then, a bulk edit can be used to update field values of a lot of records. Excel can also be used to import or edit existing records, there is even an option that uses Excel Online to edit the content of a Dataverse table.

Finally, if you need to curate the data of a table you can create a query that returns the records to delete and then configure a bulk delete job based on the query.

Document generation

Of course developing an app is often a way of getting rid of document based processes. Nonetheless, it can be useful to generate documents based on records. You could for example generate a memo from a record in order to approve it with an electronic signature software. In that case you could use the built-in document generation feature of MDA. You download a Word template that contains XML fields. After customizing the template and uploading it to your app any user will be able to generate the document based on a record’s values.

Same thing can be achieve to generate an Excel file based on a view.

I find this feature limited (no way to insert rich text content for example) but it works and is quick to configure.

Advanced security model

Dataverse uses a hierarchical security model that can be used to represent the different business units and teams of an organization. In addition to that the concept of ownership is very useful to restrict who can or cannot access a record. You can for example restrict the records a user can create, update or delete to the ones he/she owns or the ones owned by his/her team or even to the ones owned by a subordinate team.

Field level security is also a feature provided by Dataverse that can be very useful. See links below if you want to know more about security in Dataverse.

On the contrary, even though you can set the security at the item level in SharePoint it is not recommended and should be the exception. Also, it is quite difficult to see who has access to what when securing a SharePoint site at the list level or item level.

Mobile support

Native iOS and Android apps are available and provide offline capabilities. Very few configuration is required to make an app available on mobile.

On the other hand a SharePoint app is available but is pretty much useless at the point I always use the OneDrive app to access my documents and libraries instead of the SharePoint app.

ALM

MDA can be packaged in solutions that make your app easy to deploy from one environment to another. Even though it is almost impossible to merge changes as you would do with other development frameworks and platforms you can still extract and the content of a solution in a source control.

Microsoft is also providing tools to automate the deployment of solutions. Azure DevOps tasks are available to export, import and publish solutions. A backup task can even be used to ensure you keep a copy of the environment before making a deployment.

Unfortunately SharePoint Online does not give you much if you want to stage your changes. In most cases lot of changes must be done manually in different environments.

Conclusion

Those are the main things I can think of that differentiate MDA and Dataverse from SharePoint when building an app.

Don’t get me wrong, I’m not saying SharePoint is a bad platform. I think it is actually a good Enterprise Document Management system very well integrated with the M365 ecosystem.

Nonetheless, SharePoint has never been designed to build apps. Yes you can very easily create lists and with some Power Automate and Canvas App you can create solutions to support business processes but at the end of the day you won’t match the level of robustness as you will with MDA and you will find limitations quickly.

I think SharePoint has extensively been used in a lot of organizations to build apps since users are looking for a no-code platform. Unfortunately Microsoft has not provided a viable option yet in my opinion.

So you are looking for a no-code platform integrated with M365 that can be used by any user in your organization, SharePoint is still the only option but be aware of the limitations.

On the other hand if you are looking for a low-code platform that can handle complex business processes, lot of tables and relationships but that doesn’t require UI customization and extensive corporate branding, then you may consider MDA and Dataverse.