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.
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
.png?ver=tun9K3Mo7lqiYXby24q9sg%3d%3d "power-apps-security")
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).
And as we can see, the data in the Code column can already be viewed without being able to modify it.
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.