Studio Creatio
PDF
This documentation is valid for Creatio version 7.16.0. We recommend using the newest version of Creatio documentation.

Managing column permissions

Object columns are displayed in the form of fields on pages and section/detail lists. Column permissions enable you to limit access to read or edit individual object fields for users or roles. For example, you can limit permissions to read data in the [Annual revenue] field for the “Secretaries” organizational role and enable all other employees to read the data in that field. The users who do not have permission to read data in the [Annual revenue] field will see the field itself, but its value will not be displayed (Fig. 1).

Fig. 1 The [Annual revenue] field with limited access permissions

chapter_object_permissions_column_permissions_result.png 

Object operation and record permissions override column permissions. For example, if the user does not have permission to read an object data, the object will not be displayed for that user at all, and any column permissions will be irrelevant.

Attention

Before setting up object column permissions, make sure that the user or role has access to the corresponding object operations and records. Note that if an object is not managed by operations and records, all users and roles have full access to all operations and all records. Learn more about limiting access permissions to create, edit, read or delete object data in the “Managing object operation permissions” article.

In this article, we are going to look at the process of granting or limiting access permissions to read and edit data in separate fields.

Case

Set up permissions to the [Annual revenue] field on the account page. All company’s employees, apart from its secretaries, should have access permissions to read the data in the [Annual revenue] field, while the sales managers should be able to read and edit data in that field.

The field value is hidden for the company’s secretaries.

1.Go to the system designer (btn_system_designer00011.png button) and open the [Object permissions] section.

2.Select the necessary object in the list or use the search box. For example, to configure access permissions to the [Annual revenue] field, select the “Sections” filter and choose the “Account” object. Click the name (or title) of the object to open the object permissions settings window.

Note

Learn more about locating the object in the list and selecting it for access permissions configuration in the “Selecting an object to set up access permissions” article.

3.Make sure that the necessary users or roles already have access to object operations (or that the object is not administered by operations).

4.Enable the “Use column permissions” switch (Fig. 2).

Fig. 2 Enabling column permissions

chapter_objects_permissions_section_permissions_administer_by_columns.png 

Note

If a new column is added to the object, and this object uses column permissions, then the users, except for system administrators, will not be able to access that column by default. You need to set up permissions for each custom column that you add after enabling column permissions in an object.

5.Click [Add] and select the necessary column. For example, to limit access to the [Annual revenue] field, type “Annual revenue” in the search box and click [Select]. The selected column will be displayed in the list on the left. The list on the right enables you to select users and roles to configure access permissions (Fig. 3). You can add other columns, if necessary. Select a column in the list to configure its access permissions.

6.Click [Add] in the list on the right, then select users and roles. You can use the search box or the [Organizational roles], [Functional roles] and [Users] tabs to quickly find users and roles in the selection window (Fig. 3). In this case:

The “All employees” role (added automatically).

The “Sales managers” organizational role.

The “Secretaries” organizational role.

Fig. 3  Selecting the [Annual revenue] column and adding users and roles to configure access permissions

chapter_obgect_permissions_administer_by_columns_adding_roles_and_users.gif 

By default, each user or role added to the list is granted access to read, update and delete the column value. Modify permissions to restrict access. For example:

Change access permissions for the “All employees” role to “Permit reading”. As a result, all company’s employees will be able to see the [Annual revenue] field value on the account page, without the ability to edit it.

Select the “Permit reading and editing” access permission level for the ”Sales managers” role. As a result, the sales managers will be able to read and edit the value of the [Annual revenue] field.

Select the “Deny reading and editing” access permissions level for the “Secretaries” role. As a result, the company’s secretaries will not be able to see the [Annual revenue] field.

The icn_access_rights_priority00012.png icon may appear next to some permissions. That means these permissions are in “conflict”, and it is necessary to change their priority so that the settings can be applied correctly.

Hierarchy of column permissions

Sometimes different access permissions applied to the same user or role may contradict each other.

For example, the “Sales Managers” and the “Secretaries” roles are included in the “All Employees” role. Sales managers have more permissions than regular employees (Fig. 4).

Fig. 4 Example of access levels contradicting each other

chapter_objects_permissions_column_permissions_priority.png 

In the case of a conflict, the permission that is the highest in the list will have a higher priority. The priority is shown in the [Priority] column and the highest possible priority is “0”. An icn_access_rights_priority00013.png icon next to some of the rules indicates that they overlap and need to be lowered or raised in the list for other rules to work correctly.

Follow these rules while configuring access permission priorities:

  • Object operation permissions and record permissions have higher priority.

  • A user who has several roles will get the access permissions of the highest role in the list.

For example, you can deny editing access for all employees, and grant sales managers the permissions to read and edit this field. To do this, place the “Sales managers” role higher than “All employees” in the list.

  • If you deny access to a column for a user, place this role higher in the list than any roles who have permission to access the column.

For example, to deny access to read and edit column data for all secretaries, the “Secretaries” role should be placed higher than the “All employees” role (which has permissions to read the column data) in the list. In this case, the icn_access_rights_priority00014.png icon will be displayed next to the “Secretaries” role.

Note

In this case, there is no need to change the priority, since the secretaries are not supposed to view the column value, according to our example.

  • The access permissions for users or roles that have not been added to the column permissions settings area correspond to the object operation permissions that are configured for them.

Configure access permission priorities for the example above. To change the rule display order, drag&drop the rule to the necessary position in the list (Fig. 5).

1.Place the organizational role with the highest level of permissions (in our case, “Sales managers”) at the top of the list.

2.Place the “Secretaries” role directly below the “Sales managers” role.

3.Place the “All employees” role at the very bottom of the list.

4.Save the changes by clicking “Apply” in the upper left corner of the page.

Fig. 5 An example of configuring access permission priority

chapter_objects_permissions_column_permissions_priority_2.png 

As a result:

  • Users that are part of the “Sales managers” role will have the ability to read and edit the [Annual revenue] field value.

  • All secretaries will not be able to see the field on the account page.

  • All company’s employees will be able to see the [Annual revenue] field value on the account page, without the ability to edit it.

See also

Managing object operation permissions

Managing record permissions

 

Did you find this information useful?

How can we improve it?