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.