Best Practices when working with Dataverse

Create within a solution

Defintely one of the first things I am recommending everyone starting with Dataverse. At least create your own publisher and solution, and start working with the solution. You will benefit not only from the naming, as the prefix will be based on your publisher, you can also start thinking about ALM processes. Have a look at the post regarding Publishers and Solutions

Create tables in the base language

Don’t mix languages to overcome tranlations.
I always recommend to install Dataverse with English as base language, even though your current app language may only be German or any other language. Nevertheless, tha base language is the fallback langhuage if something is not yet translated.
Maybe your current scope has only one language but in the future additonal languages shoul be installed. Or you are changing the developers. If you have used a different language as base language, you might get some complications later.
And to make it even worse - lets assume you have setuo dataverse with english as base language and have installed the necessary language pack. Instead of creating your cuustom tables now in English (your bas language) you think you are smart and directly create the tables in your custom language to overcome translation effort.
This is by far the worst decision that you can make. You may save minutes, but by creating these kind of mixed up solutions, all translations, coding, even working with Power Automate or Canvas Apps will be frustrating because you never know, what will be the correct term to select something.
And even if your current scope of the project might be a good reason for you to take such a decision, you never know if you have to integrate the solution later on with other systems or the data should be part of some Reporting. And you cannot change schema names later on.
So once you have created sometihing like this, the effort to clean up such a solution will be definitely a multiple of the original effort and translation together.
Before you could clean up something like this, even without data in the system, you have to remove all dependencies first - from all artifacts. And then you have to rebuild everything. And if you have data in your system already - you have additional data migration effort as well.

Set table Ownership correctly

Take your time and think about the requiremenats of a table. Changing the ownership of a table later is not possible. Sometimes it may look like, that setting ownership to organization is a good approach, as you do not have to configure so much security settings. But in most cases the opposite is the case. Once you have the requirements and only organizational ownership, you do not have any option to configure specific permissions based on different profiles.

Only activate features that you really need

Same recommendation here. It is great, what Dataverse offers you out of the box. And also which options you can activate with a table. But some of these options can only be changed once - when activated, there is no way back without deleting the table and setting up everything again.
And if you activate options, you should always have in mind, what will be the impact of this decision. Any functionality, that will be added, and you don’t need, or which shouldn’t be allowed at all and you have now to deal with more complex scenarios? Or performance impact? Don’t take decisions to easy at the beginning. And test the functionalities best before in a dev or trial environment, so that you really know, eaht will happen once you activate the functionality.

Set table image

In comparion to the first ones - this is really an optional recommendation. But nevertheless, if you have an icon that you can use for your table, add it directly. The Look and Feel, Usability and User Experience of your applications is directly different, when you have a dedicated icon set and not just another piece icon in the menu.

Be consistent in naming (columns, etc.)

This is not only a dataverse related best practice. This is true for everything. Creating tables, columns, forms, views, sections - you name it in Dataverse, or adding components to a Canvas App, Creating triggers and Actions in Power Automate or whatever else. Use naming conventions when working alone or even more when collaborating with others.

• This starts with working in solution, so every component has the same prefix.
• Define how schema names should be created - everything lowercase or PascalCase?
• Do you want to use specific suffixes e.g. Id for Lookups or code for Choice? You can define your own style for your team and projects - but be consistent. If you have to look at your code after 6 months, or someone else is resposnible later on - this will definitely help you.

Do not use Display name multiple times

Do not use the same Display name multiple times on the same table, even if it is possible. You will have problems to identify the correct column e.g., to add the column to a form or view and excel export will not work as well, as in excel columns with the same name are not allowed. If there is already a column with the same name, that you cannot use for whatever reasons and also cannot remove as it is e.g. an OotB column, rename the display name of the one you don’t use.

Think about Global or local choice

When it comes to choice columns, you can decide if you want to have a global or local choice. There are reasons why you either choose one or the other. Local choice columns can be more specific to a single table. And you can decide more flexible without impacting other columns or tables when you need to update or change choice values. Global choice columns are more consistent throughout the whole application. If you have mapping between different tables, global choice columns will ensure, that the mapped values are definitely the same. And it is also more efficient, to have a defined Global choice set, that you know you have to reuse the exact values at different tables. On the other side, you do not want to overgeneralize choice columns by using always global choice option, and you risk to be more inflexible.

Check existing column properties

It does not matter if you are using only Core Common Data Model or additional Dynamics 365 applications or any other 3rd party data model extension. You should always verify that the column properties are matching your specific needs. Therefore, you should have a look e.g. at the search settings as well as the audit settings of the columns as these settings will have impact on performance, usability and also data storage consumption.

Check and define relationships

In dataverse you will always have existing Ootb and custom relationships between tables. When defining the relatonships between tables, it is not only important to have the correct relationship (1:n, n:n or custom n:n) but you should also have a look at the behavior of the relationship. Especially to verify how child ar activity records behave in case of ownership change. This can result in some very strange or unwanted behavior. In addition, make sure that when you are using mapping between tables, the correct columns are mapped, as well as the limitations of mapping are ok for your process. If you need e.g. additional updates of child records after the creation, make sure, that this is covered by additional logic as mapping will only work during the creation process.