CDESK offers several access control mechanisms that complement each other, making it easier to navigate the system. Their functionality is explained in more detail in separate sections of the documentation: Initial configuration of permissions and data access.
When making requests available to system users, it is important to pay attention to the underlying mechanism, which consists of and the global settings at. These settings ensure that if a feature is disabled, it will not be displayed to anyone in the system, regardless of their assigned permissions.
Global settings for the Requests module are available at Global Settings → Requests, and these settings are further organized by category. Each category of settings is covered in detail in separate sections of the documentation: Basic Settings, Request Statuses, and Service Types, Categories, and Areas.
The following diagram illustrates the logic and scope of access to and request records for individual users in the CDESK system. It shows how the resulting set of visible requests is composed of several parallel mechanisms that combine with one another. The resulting user access is not determined by a single setting, but by a combination of all active permissions, links, and rules. The diagram is available for download at and in PDF format here.
In the initial configuration, the system grants users who are not administrators a limited scope of requests based on their role and basic permissions. This scope can subsequently be expanded through a combination of additional access mechanisms, such as company visibility settings, permissions for third-party requests, or links to the organizational structure.
The individual columns of the diagram represent separate access mechanisms that operate independently of one another:
- based on company visibility,
- based on user permissions,
- from subordinate objects,
- from the request type manager role,
- by selecting specific requests.
Each branch within a column represents a specific configuration method, such as manual selection of companies, filtering by type or category, or linking to a service area, facility, or organizational unit. These mechanisms can be used individually or in combination, and the user sees every request to which they have access via at least one of the listed methods.
Access can be configured:
- As a whole – for example, by allowing all requests from visible companies, which you can also make available in bulk, such as by company type.
- Based on defined criteria – for example, by making available only selected types or categories of requests, or only records linked to a specific facility or service area.
Configuring Permissions for Access to Requests
The second mechanism involves permissions for users. User access to request records depends on a combination of two factors—assigned permissions and visibility settings. Permissions determine what actions a user can perform on a request (such as creating, changing status, closing, or assigning). Visibility, in turn, defines which objects—such as requests and contacts—are displayed to the user in the system.
During the initial system configuration, each user is assigned a set of permissions corresponding to their role on the team. As a result, a customer has a more limited set of permissions than an assignee, operator, or administrator.
You can freely add to the assigned permissions as needed; we recommend using groups with permission inheritance. For details on the scope of permissions, see the documentation section Introduction to Accessing Features and Data.
Default permissions for primary user groups
The default set of permissions is configured so that every user, even those with a free license, can view records in the system. Users can thus view any objects in CDESK, such as requests, discussions, or other related information. Each license also provides access to creating requests or managing discussions.
However, some advanced features are reserved for paid licenses. For example, customers with a free license cannot change the status of a request or the assignee. They also do not have access to certain fields—though this access can be added later.
Another set of restrictions applies to features directly related to billing for services—for example, fulfilment entry, leave request, loan request, or approval functions for customer accounts. These features are automatically included in paid assignee licenses at no additional cost.
Basic permissions for working with requests by user group:
- A default set of permissions focused primarily on reading records; in some cases, writing can also be enabled
- Access to your own requests, requests by organizational structure, and by visible deals
- Creating requests—by manually entering data or via the Request Catalog
- Option to start a discussion with the customer
Detailed overview
- display of the Requests module in the menu
- access to request records assigned to them or to their organizational structure
- access to request records from visible deals
- access to fields – visibility and editing (custom request codes – not editable, org. unit, completion deadline from, assignee, assignee group, watchers – not editable, complaint assignee, priority, urgency, impact, internal note, internal attachments, request weight, supplier, workload calendar, categories, attachments, type, percent complete, planning mode)
- access to tabs in the request details (Tasks, Work Orders, Fulfilments, Discussion, History, Offers, Purchase orders, Request Invoice, Jira, Scheduled Work, Related Requests, Attached External Requests, CMDB, Ext-mail)
- access to customer discussions, internal discussions, discussion templates, and Jira comments
- ability to create new requests by manual entry (general request)
- ability to create new requests via the Request Catalog
- ability to create internal requests
- ability to change the request status
- ability to close, quickly close, reopen, and accept the closure of a request
- access to work order records, including internal discussions and the option to quickly close
- A minimalist set of permissions focused on providing access to assigned records and related information
- Access to own requests, requests by organizational structure, and by visible deals
- Creating requests and internal requests – by manually entering data or via the Request Catalog
- Ability to discuss with the customer and engage in internal discussions
- Ability to change the status of a request and the assignee
- Access to work deal records
Detailed overview
- Module view Requests in the menu
- access to request records assigned to him or his organizational structure
- access to request records from visible orders
- access to fields – visibility and editing (custom request codes – cannot be edited, org. department, due date from, assignee, assignee group, follower – non-editable, reported assignee, priority, urgency, impact, internal note, internal attachments, request weight, supplier, workload calendar, categories, attachments, type, percentage complete, planning mode)
- access to tabs in the request details (Tasks, Work Orders, Fulfilments, Discussion, History, Offers, Purchase orders, Request Invoice, Jira, Planned Work, Related Requests, Attached External Requests, CMDB, Ext-mail)
- access to customer discussions, internal discussions, discussion templates, and Jira comments
- ability to create new requests by manually filling out (general request)
- ability to create new requests via the Request Catalog
- ability to create internal requests
- ability to change request status
- ability to close, quickly close, reopen, and accept the closure of a request
- access to work order records, including internal discussions and the ability to quickly close
- Access to your own and others’ requests, to subordinates’ records, to requests by organizational structure, and by visible deals
- Creating requests and internal requests – by manually entering data or via the Request Catalog
- Ability to discuss with the customer and engage in internal discussions
- Ability to change the request status
- Access to work deal records
Detailed overview
- View the module Requests in the menu
- Access to request records assigned to him, his organizational structure, or his subordinates
- Access to request records from visible orders
- Access to all request fields
- Access to tabs in the request details (Tasks, Work Orders, Fulfilments, Discussion, History, Offers, Purchase orders, Request Invoice, Jira, Planned Work, Related Requests, Attached External Requests, CMDB, Ext-mail)
- access to customer discussions, internal discussions, discussion templates, and Jira comments
- ability to create new requests by manual entry (general request)
- ability to create new requests via the Request Catalog
- ability to create internal requests
- ability to close, quickly close, reopen, and accept the closure of a request
- access to work order records, including internal discussions and the option to quickly close
Unrestricted access to all records and features.
Managing access to requests based on jurisdiction
In the CDESK system, you can precisely configure which requests will be visible to individual users and which will remain hidden. There are several mechanisms and options for achieving the desired visibility and access to requests—ranging from simple access based on companies to detailed permissions tied to the organizational structure. In practice, there is often a need for some users to see only their own requests, others to see the requests of their colleagues or subordinates, and administrators, naturally, to see everything. Basic methods for configuring request visibility, including company visibility settings, are described in the documentation sections Introduction to Accessing Features and Data. To cover more complex scenarios, CDESK offers additional mechanisms that can be flexibly combined:
- Access based on company visibility – the user has access only to requests belonging to companies that they have set as visible. Requests from invisible companies are made available only if the user holds a specific role on the request (e.g., Lead assignee, Co-assignee), or if access is granted through another authorized mechanism (e.g., Optional assignee, Representation).
- Distinguishing between own and third-party requests – own requests are those in which the user acts in one of the roles on the request (e.g., assignee, requester, on behalf of, creator), or requests to which the user has gained access through visibility and permission mechanisms (excluding permissions Access to third-party). Requests that cannot be made accessible through these mechanisms are considered third-party.
- Access based on a project – without permission to access third-party requests, users can only access their own records, such as where they are listed as a (co-)assignee; access to other requests is possible through the project to which the third-party request belongs. The logged-in user must be listed in the project as Responsible person.
- Access based on project deal – without authorization to access others’ records, the user can only access their own records, for example where they are listed as a (co-)assignee; access to other requests is possible through the project deal to which the external request belongs. The logged-in user must be listed in the project deal as Project Manager, Project Team Member or Observer.
- Access control based on user hierarchy – when the permission is enabled Access to subordinates’ records a superior user has access to their subordinates’ requests. This permission also applies to further levels – the user can thus see the requests of their subordinates’ subordinates, and so on down the entire hierarchy. Superiority can be set manually in the user details.
- Access control based on organizational structure – with the active AD connector, it is possible to enable the permission Access based on the record’s organizational unit, where the user is granted access to requests belonging to their unit and all lower levels. The condition is that the Organizational Unit field must be filled in on the request – only then can the request be assigned to the appropriate unit.
- Access based on request type – option to designate a manager responsible for a specific request type, who, regardless of access permissions to third-party or other request records, gains access to requests of that type for companies visible to them.
- Selecting specific requests – for specific scenarios, it is also possible to define exceptions – for example, so that a user has access only to specific request records. Access can be specified in the user details, in the section Permissions, after clicking the gear icon in the section Requests → Records.
Company visibility
The visibility of requests in the CDESK system is largely controlled by and the visibility settings of the companies to which the requests are linked. A user has access only to those requests that belong to companies they have set as visible, unless the request is made accessible through another mechanism (e.g., via the Assignee, Assistant Assignee, or Responsible Person fields).
Company visibility can be configured from both sides:
- on the user side – by directly assigning specific companies or in bulk by category and company type, or by inheriting settings from groups,
- on the company side – by defining the users and assignees to whom it should be made available.
By combining these settings, the system determines the final scope of visible requests for a specific user. A detailed description of the individual options and procedures is provided in the documentation section Introduction to Accessing Features and Data.
Making requests from invisible companies available
An assignee who does not have access to a request through any other means will gain access to it if one of the following fields is filled in:
- Assignee
- Co-assignee
The request will be made available to the user even if they are listed in the Responsible person field. The assignee in question must have the company visible in order to be set as the responsible person. This restriction does not apply to the Assignee and Optional assignee fields. Requests will also be made available to a user acting as a substitute.
Access to requests for the "Optional Assignee" role
In CDESK, there may be situations where a request is made available to a assignee even if they do not have visibility into the company to which the request is assigned. These are specific scenarios in which standard visibility based on companies does not apply exclusively; instead, other mechanisms related to permissions and links to the request take precedence.
Typically, this applies to cases where a user is designated as an optional assignee for selected companies, specific types, or categories of companies. In this case, other assignees can select this assignee on a request for companies they do not normally see.
This setting is available in the user details on the tab Companies (Users and Groups →Users→DetailsRecord SpecificUser→Tab Companies). To correctly apply access to records belonging to individual invisible companies (at the bottom of the screen Settings for selected companies), it is necessary that is enabled only the functionality Optional assignee and are disabled the functionality Assigned to company and Visible company. Or allow other assignees to select a assignee based on company types and categories (in the upper right corner of Optional assignee for other assignees by category/type company).
Access to requests for a substitute user
When actively representing another user, the range of available requests is expanded to include the requests of the represented user. In addition to their own requests, the logged-in user will also have access to those records to which the represented user has authorized access, depending on the represented user’s role and visibility settings.
Access to requests when acting as a proxy works as follows:
- A logged-in user can view the requests of the user they are representing in the same way as if that user were logged in directly.
- Other rules regarding access to requests remain in effect.
When acting on behalf of a user with a customer account, the following additional condition applies:
- The requests of the user being represented will only be made available if the logged-in user has the same visible companies set as the user being represented.
- If the condition of matching visible companies is not met, the requests of the client account will not be displayed during delegation, even in the case of active delegation.
Access to your own requests
Access to own requests is available to any user with access to the Requests module and with the permission for Records enabled. This access is configured in the permissions settings (under Users and groups → Users → record details for a specific user → tab Permissions → section Requests).
To ensure that users can only access their own requests, the following permissions must be disabled:
- Access to other users’ requests
- Access to subordinates’ records
- Access to records from visible deals
The list of custom requests for the role assignee / operator consists of records where the logged-in user is in one of the following roles:
- is the record creator
- is the assignee
- is the responsible person
- is the assistant assignee
- is listed in the “Who is requesting” field / For whom is the request being made
- is a substitute for one of the roles listed above
- records assigned to the research group of which the logged-in researcher is a member – however, only records to which the user has access are visible
- records where the user’s assignee group is set as a co-assignee – however, only records to which the user has access are visible
The list of own requests for the customer account role consists of records where the logged-in user is in one of the following roles:
- is the record creator
- is listed in the “Who is requesting / For whom is requesting” field
- is a substitution for one of the roles listed above (if the substitution conditions are met)
A user who has access to Records but only for reading
will not be able to make any changes to requests. To allow changes, you must also grant permission for to edit items
. If the ability to delete requests is also required, you must also grant permission to to delete records
. If permission to edit/delete is granted only in the section Records and these permissions are not granted for other requests, the user will only be able to edit/delete their own requests.
The user’s own requests also include requests made available through visibility and permission mechanisms, such as:
- making a subordinate’s requests available,
- making requests available based on the user’s organizational unit,
- making requests available based on a visible deal.
Detailed information on the individual access mechanisms is provided in the separate sections of the documentation below.
Access to third-party requests
Third-party requests include all records that do not belong to the set of the user’s own requests. The visibility of these records depends on two conditions:
- Permission to Access third-party records is enabled – this permission can be enabled in the user’s details, under Permissions, in the Requests → Records section.
- Visible companies – the user can primarily access records of companies that are visible to them. It is not enough to simply have the Access to third-party permission enabled.
If both conditions are met, the user will have access to all requests from visible companies, except for those restricted by service area, category, or operation within the request. The ability to work with records (e.g., editing) may be further restricted by additional permissions that determine the scope of allowed operations on the record.
Restricting access based on the service area of the request
The display restriction based on service area can only be applied to users who have the Access to others’ records permission enabled. By default, this option is available for user accounts of the assignee and operator types.
For a customer account, the service-area restriction is available only if the account is assigned to a user group you have created. No additional settings are required at the group level—it is sufficient for the customer account to be a member of that group.
You can configure the restriction of the list of requests by service area on the Service Areas tab, which is displayed in the user form (Users and Groups → Users → record detail of a specific user → tab Service Areas). If this tab does not appear in the customer account, the account must be assigned to a user group.
This tab displays a list of all service areas. Service areas can be defined in the following sections: Global Settings →Requests →Types,Categories and Service Areas. Instructions for defining service areas are available in the documentation section Types, Categories, and Service Areas.
There is a checkbox next to each area. After selecting a specific area on 
, the user will only see requests where that area has been filled in. If no area is checked in the list, no restriction will apply, and the user will see all requests regardless of which service area is selected. Similarly, no restriction will apply if all service areas are selected.
Access restrictions by request category
The display restriction based on request category can only be applied to users who have the Access to third-party permission enabled. This option is available for all account types.
This restriction on viewing requests works in the same way as the restriction on access based on the request service area. The restriction can be set on the Categories Requests tab, which is displayed in the user form (Users and Groups →Users →Detail Record of a specific User→Categories Requests tab).
This tab displays a list of all request categories. Request categories can be defined in the section Global settings → Requests → Types, categories and service areas. Instructions for defining request categories are available in the documentation section Types, categories, and service areas.
There is a checkbox next to each category. After selecting a specific category of requests (), the user will only see those requests that have that category selected. If no category is checked in the list, no restriction will be applied, and the user will see all requests regardless of the selected request category. Similarly, no restriction will be applied if all request categories are checked.
Access restriction based on the operation specified in the request
The restriction on viewing based on the operation can only be applied to users who have the permission enabled: “Access to third-party.” This option is available for all account types.
This restriction on viewing requests works in the same way as the access restriction based on service area or request category. The restriction can be set on the Locations tab, which is displayed in the user form (Users and Groups →Users→detail record of a specific user →tab Locations). Unless the visibility of specific locations is selected, all of the company’s locations and sites are visible to that account.
This tab displays a list of all facilities registered for each company. Facilities can be defined as separate CI items within the CMDB configuration database. Instructions for creating CI items are available in the documentation section Manual creation of CI items.
There is a checkbox next to each facility. After selecting a specific entry (), the user will only see those requests for which a facility has been selected. If no facility is checked in the list, no restriction will apply, and the user will see all requests regardless of the selected facility. Similarly, no restriction will apply if all facilities are selected.
Access based on superior and subordinate users
When granting the permission for Access to subordinates’ records, a superior user gains access to the requests of their subordinates, as well as those of their subordinates, provided they appear in at least one of the following fields:
- Created by
- Who is requesting
- For whom is the request being made
- Assignee
- Auxiliary assignee
- Responsible person
The user must be selected directly in these fields, not their group. If a group to which the subordinate belongs is entered in any of the fields listed above but the subordinate is not selected directly, the supervisor will not see the record.
The user hierarchy can be configured manually in the user details, on the Superiors and Subordinates tab. Clicking the + button next to the section name opens a modal window for selecting users. You can select a superior or subordinate by double-clicking the row containing the desired user. You can also set the notification scope for each user.
The diagram above illustrates a specific combination of permitted and restricted permissions that must be adhered to for proper access to subordinate records. Any additional permissions regarding record visibility granted to the user subsequently expand the set of requests they will see beyond those of their subordinates.
A user who has the Access to subordinate records permission with only access / read enabled will not be able to make any changes to subordinate requests; they will only see them. To allow changes, you must enable the permission to edit items . If the ability to delete subordinate requests is also required, you must also enable the permission to delete records . If the permission to edit/delete is enabled only in the Access to subordinate records section and these permissions are not enabled for other requests, the user will only be able to edit/delete their subordinates’ requests.
Access based on organizational structure
When the Access by record’s organizational unit permission is enabled, the user gains access to all requests for the unit to which they belong, as well as all organizational units subordinate to it. If necessary, it is possible to manually select additional organizational units whose requests will be accessible to the user.
The permission can be configured in the user details, in the Permissions section, under Requests → Records. However, this permission is only available if an active AD connector is configured in your environment. After configuring the connector, the Organizational Structure tab will appear in the user form, displaying the company’s organizational structure and the user’s position within it.
A higher organizational unit level does not automatically mean that users from that higher level are the supervisor of a given user. The determination of subordinate and supervisor users is not dependent on the organizational unit; it is a native feature that we will discuss in the next section of this documentation. The visibility of other departments can be adjusted by clicking the gear icon in the permissions row Access by org.department record – by enabling visibility of the superior department the user gains access to the requests of that department and all departments lower in the hierarchy.
To ensure that requests are correctly assigned to the appropriate departments, the Organizational Unit field in the request form must be filled out. This field is automatically pre-filled based on the requester’s organizational unit and can be edited. Without a specified organizational unit, it is not possible to evaluate whether the request record should be made available.
The diagram above illustrates a specific combination of permitted and restricted permissions that must be adhered to for access based on organizational unit to function properly. All additional permissions regarding record visibility granted to the user subsequently expand the set of requests they will see beyond those linked to the organizational unit.
A user who, for the permission Access by org.department record, has only the permission access / readenabled, will not be able to make any changes to requests linked to the organizational units available to them. To allow changes, it is necessary to enable the permission for editing items. If the ability to delete these requests is also required, you must also grant permission for deletion of records. If the permission to edit/delete is granted only for specific organizational units in the section Access by org.unit of the record and these permissions are not granted for other requests, the user will be able to edit/delete only those requests that are linked to the organizational units accessible to them.
Making requests available by deal
When the Access to records from visible deals permission is enabled, the user can view all requests linked to the deals to which they have access. No special role is required to access requests—it is sufficient for the user to see the deal itself. If the deal is visible to the user, all requests assigned to it will also be made available. At the same time, only requests belonging to companies that are visible for the given account will be made available.
This method of access is particularly useful when a user is working with deals and needs an overview of all the requests associated with them, such as for back-office tasks or invoicing.
The diagram above illustrates a specific combination of permitted and restricted permissions that must be adhered to for deal-based access to function properly. Any additional permissions regarding record visibility granted to the user subsequently expand the set of requests they can view beyond those linked to deals.
A user who has the Access to records from visible deals permission set only to access / read will not be able to make any changes to requests linked to deals visible to them. To allow changes, you must also grant the editing of items permission . If the ability to delete these requests is also required, you must also grant the deletion of records permission . If the permission to edit/delete is enabled only in the Access records from visible deals section and these permissions are not enabled for other requests, the user will only be able to edit/delete requests linked to deals that are visible to that user.
Access based on the request type manager
Access to request records can also be determined based on their type. For each type of request recorded in the system, you can designate a manager responsible for the type of request, who, regardless of access permissions to third-party or other accessible request records, will gain access to requests of that type for the companies visible to them.
You can assign a manager for each request type individually in the section Global Settings →Requests →Types,Categories and Areas Services. Clicking the gear icon 
in the row for the desired type will display a modal window with the relevant settings. You can select a specific user or user group as the manager.
Unlike other options for configuring access to request records, which restrict the set of accessible records, this approach, on the contrary, expands the set of accessible requests. An example would be making records from visible deals accessible and designating the manager as type Fault – a user with this permission configuration has access to requests from visible deals as well as to all requests of type Fault (regardless of the link to the deal).
Selection of specific requests
In practice, a situation may arise where the permissions described above grant access to requests, but it is not desirable for the user to access all of these requests. In such cases, it is possible to restrict access to specific records.
To restrict access to specific records, click the icon located in the Records permission row.
Clicking this button displays a modal window listing the available records. The search field located above the list is used to search for specific records. Each record’s row contains icons for the “View record” permission (), the “Edit record” permission (), and the “Delete record” permission (). Clicking on any of these icons in the row of a specific record changes the permissions for that record only. In this way, it is only possible to restrict permissions for already accessible requests. It is not possible to grant access to a request that does not fall within the permissions of the given user. For example, if a user has access only to their own requests, it is not possible to grant them access to someone else’s request.
