In addition to the usual setting of access to modules and records, CDESK offers three tools for situations that cannot be solved with the standard levels. What they have in common is that they are used only exceptionally and do not need to be changed in a typical environment configuration.
Special permissions
The Permissions (special) column contains additional permissions that cannot be expressed by the four levels of access, editing, creating and deleting. They include, for example, access to the internal discussion, to internal and sensitive attachments, displaying the assignee’s note to someone who is not an assignee of the record, or editing user-defined fields.
You will not see them on the main module rows; they are located only at the lower levels of the tree, so the relevant branch has to be expanded first. Above the switches it is always stated what they relate to, and each one has a description of its meaning.
These are solutions for specific situations that cannot be expressed with the standard levels. That is why they are set only when you really have such a need. Special permissions are set with the same three-state switches and are inherited in the same way as ordinary permissions, including the inheritance graph.
Permissions for individual records
For items of the Records type, there is a button with a gear icon next to the name. It opens the Permission settings for records window, in which permissions can be set for specific individual records beyond what applies to the whole module.
The window sets the access, editing and deleting levels (creating is not offered at the level of an individual record because it makes no sense). The switches again show in a faded colour the value that the record would take over from the setting of the whole module.
Since the whole permission system is built on grouping and inheritance, an individual setting on a specific record is an exceptional tool. It is used to solve situations that cannot be solved through groups or would take too long that way. A typical example is a sensitive request that has to exist in the system but must not be seen by anyone except two specific people. On that record, access is denied across the board and individually allowed for these two accounts. The problem is solved immediately and without touching the settings of the whole environment.
If some records have their own setting, the number of such records is shown next to the gear icon. This way you can see in the tree where individual settings exist.
Warning: Permissions for individual records are saved separately, directly in this window. They are not saved together with the user or group form, and the Discard changes button does not apply to them.
Permissions for user fields
User-defined fields are set in two different places in the tree, and each of them has a different reach. The first acts on the property as such and applies across the whole of CDESK; the second deals with the individual fields on a record and is available only in the configuration database. For both, it is also necessary to distinguish the configuration of a field from access to its values – confusing the two is the most common source of misunderstandings.
Permissions at the property level
This is set in the permissions of a specific user or group, in the CMDB → User-defined fields branch, which has the Basic properties and User fields sections, each with its own Records item.
The write, create and delete permissions for these items affect the configuration of the property, not its values. If you want to set permissions for selected properties, click the gear icon 
next to this item. If you deny an account editing, it cannot edit (configure) the property in the list of basic properties, but it can still change its value in every form to which this property is linked (across the whole CDESK system).
The access / read items permission, on the other hand, behaves globally. Once access is denied, the field disappears completely – the account will not see the field or its value in any module and will not find it in the list of basic properties either. Allowed editing does not help when access is denied. If the account cannot see the field, it has nothing to edit.
Permissions at the CI item level
This is set in the permissions of a specific user or group, in the CMDB → Item (CI) → Item record → Access to fields → User-defined fields branch. Unlike the previous place, this concerns the value on the record – so you can hide a specific property on the record, or leave it visible and prevent its value from being changed.
If you want to set permissions for selected properties, click the gear icon next to this item – a list of the individual properties is displayed, and visibility and editing can be set separately for each one. For example, if a CI item records a job position, workplace and starting salary, you can hide just the starting salary and leave the other data from the same record visible.
This setting is available only within the Configuration database (CMDB) module, and its effect is also limited to this module. If the same field is also linked to the request form, the account will still see it in the request and can also edit its value – the restriction set on the CI item does not apply to other modules.