Dataverse more than a Database
Enterprise app development is moving towards low-code, high-productivity platforms with the aim of minimising costs and supporting rapidly changing business needs.
The disruptive growth will cause most users to develop applications using simplified tools.
However, regardless of the technology you adopt, you have to take into consideration the data management that will power your application.
By reading this article, you will discover the advantages of Dataverse and why its adoption can give you a significant boost over other DataSources.
We will analyse the advantages offered, the possibilities for extension and in particular see what lies behind the scenes.
Let’s get started!
The main reasons why Power Apps is adopted in application development can be summarised in its simplicity, its integration and its cost-effectiveness.
Indeed, when dealing with limited budgets, the Power Apps solution can be very fruitful.
However, if information management considerations are not taken into account, one could end up in the abyss.
Costs may rise rapidly and the application will start to wobble.
For simplicity’s sake, let us imagine that you are developing a Canvas Power Apps, as it is more sensitive to the issue of data management.
It tends to be the case that the data that feeds the application can come from various external sources.
In an ecosystem such as Power Platfom, this data is provided by the various connectors made available.
Among the different default connectors you can find the SharePoint connector, Excel, SQL, Blob Storage etc..
You might be seduced by using an Excel spreadsheet or a SharePoint list to store your information, but this could prove to be a double-edged sword.
These connectors would provide a very quick option for storage, however, the amount of data to be stored cannot be neglected.
An incorrect estimation of the amount of data could lead to problems such as long loading times, delayed component rendering and performance degradation.
Here then, for a more complex application, you might consider the Micorsoft SQL cconnector.
This solution is optimal if you already have an SQL instance.
However, even in this case there are a number of considerations to be made.
If you don’t have the resources or developers in your team capable of managing an SQL database, you may experience delays in feature development and increased running costs.
So what is left?
Dataverse, in a Power Platform context, is the ideal solution to consider.
But what is Dataverse?
Microsoft Dataverse, formerly known as Common Data Service, is the data and services platform for Dynamics 365 and the Power Platform.
The first thing you need to know is that Dataverse is API First.
This means that it adopts a design model that places APIs at the centre of the strategy, allowing the development process to be accelerated.
In addition to being consumed in traditional Power Platform services, APIs can also be invoked by external applications.
In addition to this first aspect, another advantage offered by Dataverse is related to security.
Dataverse allows you to use Azure Active Directory for conditional management and multi-factor authentication.
This feature allows you to create groups and manage even single-entity authorisations with great ease.
In a moment we will see what a Dataverse entity is.
More importantly, Dataverse is extensible.
One of the main advantages offered by Dataverse is the possibility of extending the data validation logic.
To do this, several options are available to you.
The first one I propose is the adoption of Business Rules.
Business Rules allow a non-developer to create calculated values, validate data and change the appearance of forms at runtime without the need to write custom code.
In this case, client-side logic is immediate because the rules are executed when the user opens or updates a form, while server-side logic is applied when the user, or any process, saves a record.
Clearly you can’t expect to pack all your rules into a Business Rules.
These lend themselves well to simple and circumstantial cases.
Try to respect the KISS (Keep It Simple Stupid) principle.
In the event that you notice that your Business Rules are becoming too large, well then this is a sign that you may have to retrace your steps.
You will have to adopt custom code development solutions that will allow you to extend the behaviour of the platform according to your needs.
Dataverse is thus more than just a Database.
Its adoption enables the developer to speed up and simplify database administration tasks.
In addition, backup management is handled automatically by Microsoft.
This allows you to concentrate on creating and using the data model instead of administering the database.
Implementing a solution that integrates Dataverse as a database has many other advantages :
- You don’t have to worry about how the data is stored, Microsoft takes care of that for you.
- All data is encrypted.
- Dataverse connects in different ways to support business needs. APIs, webhooks, events and data exports provide the flexibility to get data in and out.
- The properties you define on your data model are used by Dynamics 365 and Power Apps, speeding up the creation of apps.
- You can control who can access and with what permissions entities, records and fields.
- You can keep track of who modifies data.
- Validation rules can be added directly to fields.
- You can create your own business processes to ensure data quality and authorise them .
- You do not need to be a DBA to manage Dataverse tables.
OK, let’s slow down for a moment…
We got off to a flying start, and already from these initial remarks you will have guessed that Dataverse cannot be excluded in the architectural definition phase.
But what lies behind Dataverse and, more importantly, how did it come about?
One of the main problems when creating systems is the migration and integration of data.
In order to solve these data incompatibility problems, Microsoft created a shared data language, defining specifications for use by a wide range of business applications and processes.
This specification is called the Common Data Model (CDM).
Let us make it clear from the outset that the Common Data Model is not a Database but is a set of schemas defining entities, attributes, relationships and their properties.
The CDM has a main schema consisting of about 20 business entities, e.g. Account, Contact and Activity.
The Dynamics 365 and Power Platform apps use this metadata to control and improve the user experience.
The main schema is extended by other schemas to be used and adopted in other apps, such as the schemas defined for the Dynamics 365 Customer Engagement Sales app.
This means that other stakeholders can contribute their own data definitions to the CDM.
We said that the main schema is mainly composed of entities, but what are entities?
Conceptually, an entity is like a database table and the attributes of the entity correspond to the columns of the table.
An entity therefore allows us to define the structure of our data.
In fact, creating a record for an entity is like adding a row to a database table.
In order to make the adoption of these concepts friendlier, these terms have been updated as of November 2020.
We can mainly define two types of tables:
- Standard Tables:
this is a set of tables created for each instance of a Dataverse database. You can extend these tables by adding custom columns but you cannot delete them. You can also create your own tables..
- Virtual Tables:
The latter type of entity is mainly used for data migration. Since the introduction of CRUD operations on these tables, their use has undoubtedly become more interesting.
Imagine for a moment that you are commissioned a new project.
In order to keep track of all its phases, you are going to create it in a management system.
Once created, the project record will appear in a table that we call ‘PROJECTS’.
It is safe to assume that a project will have several associated tasks, so the “PROJECTS” table is linked to the “TASK” table with a 1:N relationship.
Furthermore, we can imagine that a project will have several team members, but above all that the same users may also be involved in the development of features for other projects.
We can therefore say that the table “PROJECTS” and the table “USERS” have an N:N relationship.
The possibility of linking two entities brings benefits for more efficient archiving, greater accuracy of data and the creation of better reports.