The importance of column-level security at Dataverse

The creation of security roles to access and manipulate corporate information is a critical point in security. Not all users can, or should, view or edit certain information that is not within their competencies or is sensitive. In addition to these security roles, we can use field security profiles to help us to fully define the security of all the information we have in our Dataverse database.

Security in Dataverse is defined through security roles. When defining one of these roles, we must configure, for each table, the permissions to Create, Read, Write, Delete, Append, Append To, Assign and Share. In addition, when granting these permissions we do so at the User, Business Unit, Business Unit and Secondary Business Unit and Organization levels.

Illustration 1. Security role


However, when granting these permissions at the table level, we may encounter the problem that one of the fields must have different permissions than the rest. For this, we can make use of column level security.

Let's imagine that we have a table of products and a security role for sellers that allows them to Create, Read and Write.





                                                                                                                        Illustration 2. Permissions of the Products table

We assign this role to a user and he/she will see the data of this table as follows.



Illustration 3. View of active products

Illustration 4. Product 1 form


As we can see, you can see and modify the Name, Code, Color and Size fields. We want to restrict the permissions so that you can see the Code but we do not want you to be able to modify it. We cannot do it at the table level because he would not be able to modify the rest of the fields. How do we do it then? Using column level security.

First, we edit the Code column to enable the security of the field.



Illustration 5. Editing the Code field of the Products table


Now you can neither see nor modify this field.

Illustration 6. Active products view

Illustration 7. Product 1 form

Now we will create a column security profile so that you can Read, but not Write.

Illustration 8. Add field security profile

Illustration 9. Field Security Profile


We see that in the Field Permissions section this field appears, by default, with No reading, No writing and No creation.

We edit and allow reading.


Illustration 10. Editing field security

Finally, we assign this profile to the user (or to a team to which it belongs if we want to assign it to all its members).

Illustration 11. Adding user to the field security profile

And as we can see, the data in the Code column can already be viewed without being able to modify it.

Illustration 12. View of active products

Illustration 13. Product 1 form

In this way we can give specific permissions to certain fields of a table, that do not coincide with the rest of the fields of the same one.




Related posts
How to Optimize Power Automate Flows: Part 2
Elisa Bárcena Martín  |  26 January 2023

This is the 2nd part of our last post "How to Optimize Power Automate Flows" to improve the performance of your developments

Read more
How to optimize Power Automate flows
Elisa Bárcena Martín  |  19 January 2023

Learn how to create automated workflows in Power Automate that will allow you to improve the performance of your developments in less time

Read more
Why choose Python for data loading in Power BI?
Eugenio Peraza Perera  |  17 January 2023

In this post we give you the main reasons to work with Python during import into Power BI data models

Read more