Beta version of the new documentation.

Basic Settings

The settings for and the basic functionality of requests can be found at Global Settings → Requests → Basic Settings. Only users with administrator permissions have access to these settings; other users can access them only if they have the appropriate permissions. These are general settings that allow you to adjust the options for generating and editing requests, customize the request form, configure deadlines, types, discussions, and other aspects related to requests. For clarity, these settings are divided into several sections:

  • General
  • Custom request codes
  • Separate number series
  • Discussion and ext-mail requests
  • Request deadlines
  • Request priorities
  • Items from CMDB
  • Reasons for closing a request
  • Resolution methods when closing a request
  • Request causes
  • Message for the new assignee
  • Default settings for the request list
  • User-defined fields
  • Bulk editing of request fields
  • Customersubmissions

General

In this section, you can configure the request module in general—from enabling it, through editing options and required fields, to specifying which fields will be recorded in the request form. Within the general settings, you have the following options:

  • Enable the Requests module – by toggling the switch to the “On” position, you gain access to creating and recording requests, and additional settings for this module become available. Data and access to this module are controlled by user permissions.
  • Allowed Request Types – the option Helpdesk is always enabled by default. Another option is Equipment Service – this feature is currently in beta.
  • Compact Requests – enabling this option will adjust the display of request details (does not apply to the right panel, mobile, or desktop applications). In practice, this means that the vertical spacing between items will be reduced, allowing more data to fit within the screen height.
  • Enable links between requests – when enabled, it is possible to register additional requests that are linked to the original request. In the request details, the Related Requests tab appears, where a list of linked requests is available. This feature is permission-controlled for users.
  • Default request visibility – the option to specify an automatically defaulted value in the Visibility field when entering a request. This value can be modified later while submitting or editing the request. The following options are available:
    • Normal – the request is visible to customer accounts
    • Internal – such a request is hidden from the customer account
  • Include a fulfilment report in the email about the completed request – when this option is enabled, the email about the completed request (after switching the request to the Completed status) will include a list of fulfilments recorded for the given request
  • Reset request ID at the beginning of the year – when this feature is enabled, the request ID has the format yyyy – n, where y is the year and n is the sequential number of the request in the given calendar year. At the beginning of the year, this sequence number will be automatically reset. When this feature is disabled, the request ID automatically continues based on the number of requests.
  • Setting the number series from 1.1.yyyy – this feature allows you to plan the number series for the new year. After enabling this option, a field becomes available for entering the number series, which will be applied starting from the 1st day of the new calendar year.
  • Selection of assistant assignees – this feature allows you to assign, in addition to the assignee, assistant assignees or a group with separate notification settings for the Assistant Assignee role to a request. Enabling this feature in permissions makes the Assistant Assignee field available in the request.
  • Show discussion attachments in the Basic Information tab – if this option is enabled, attachments found in discussion posts will be included in the list of request attachments on the Basic Information tab
  • Internal Attachments – when this option is enabled, the Internal Attachments field will be displayed in the request, allowing you to track attachments that are not accessible to the customer account. Access to this field is controlled by user permissions.
  • Enable the Request Account tab – when enabled, the Request Account tab appears in the request details. This tab displays a summary of the work performed, categorized under the accounting item for delivered materials and one-time fees. When prices are set for accounting items and material prices, the total amount is also displayed. The request account can be transferred to accounting software for invoicing.
  • Request Code – if enabled, a field for the request code appears in the request; this can be mandatory or optional. This code can be used for so-called request classification; it can be entered manually or pre-filled based on the request template. The request code can also be used to filter the list of requests or for evaluation in reporting. The request code cannot be used simultaneously with the custom request code.
  • Organizational Unit – option to assign a request to an existing organizational unit; filling in this field may be mandatory or optional. The organizational unit can also be used for filtering in the list of requests.
  • Selecting a Responsible Person – the option to assign a responsible person to a request, who is responsible for resolving the request and is notified according to the event settings in Global Settings → Notifications → Basic Settings. This field is also used to filter requests that the responsible employee needs to keep track of. Access to this field is controlled by user permissions. Filling out this field in a request may be mandatory or optional.
  • Who is requesting – option to specify the person who requested the submission of the request. The person can be selected from existing CDESK users, users assigned to the company, company contacts, or entered as free text. Filling in this value can be designated as mandatory or optional.
  • For whom is requesting – option to select a CDESK user, only a subordinate user, or a company contact on the request, or to enter free text for the person for whom the request is being submitted. The setting for this field is available if the setting for the Who is requesting field is set to mandatory or optional. Access to this field in the request details is controlled by user permissions.
  • Include CDESK customer accounts of the selected company on the request in the account selection in the “For whom is requesting” field for logged-in Operators – when enabled, in combination with the setting for the For whom is requesting field, customer accounts for which the selected company is visible on the request are also offered to logged-in operators for selection.
  • Include CDESK customer accounts of the selected company on the request in the account selection in the “For whom is requesting” field for logged-in Customer and Easyclick accounts – when enabled, in combination with the setting for the For whom is requesting field, customer accounts for which the selected company is visible on the request are also offered for selection for logged-in Customer and Easyclick accounts.
  • Include operator accounts in the account selection in the “For whom is requesting” field for logged-in Customer and Easyclick accounts – when enabled, in combination with the settings for the For whom field, operator accounts are also offered as a selection option for Customer and Easyclick accounts. This setting is available only if the option “Include CDESK customer accounts of the selected company on the request in the account selection in the ‘For whom is requesting’ field for logged-in Customer and Easyclick accounts” is enabled.
  • Site Selection – when enabled, the request allows you to select a site from the list of existing sites recorded in the configuration management database (CMDB). Tip: If “Responsible for Site” is enabled, you can restrict the selection of individual sites in the request.
  • Location Selection – when enabled, a field for selecting a location is available in the request, allowing you to further specify the request’s location at the customer’s site or within the company (e.g., reception, basement, boiler room, etc.). The available locations are defined in the company details (Directory → Companies, tab Locations). Access to this functionality is controlled by user permissions.
  • Limit assignee selection by assignee group – when enabled, assignee selection in requests and work deals is divided into two fields – mandatory assignee group and optional assignee, where only assignees belonging to the selected assignee group are offered for selection in the assignee field. Visibility of requests, and possibly notifications, is controlled via the assignee group. This setting is suitable for companies where requests are handled in teams. The feature is disabled by default. WARNING! Enabling this feature will cause permanent changes to the system, and it can only be disabled via a paid service.
  • Default Assignee Group – option to specify a default assignee group that will be automatically pre-filled when creating a new request, unless the assignee group is specified in another way, such as from a request template, by service area, or by company.
  • Record the Solution field – when enabled, the text field Solution will be made available in the form after saving the request, where a more detailed description of the solution can be provided. This text may be included in the email notification regarding the completed request. Access to this field is controlled by user permissions.
  • Record the Internal Note field – when enabled, the text field Internal Note will be accessible after saving the request in the form, where you can enter text that will not be accessible to customer accounts (unless they have the appropriate permission).
  • Editing the Description field after creation – when this setting is enabled, the text field containing the request description will be editable even after the request is created. Otherwise, the description field is not editable (not even by the request assignee).
  • Editing a request before assignment – when enabled, a request assigned to a assignee group can be edited by assignees belonging to that assignee group. Otherwise, a specific assignee from the given assignee group must first be assigned to the request before editing is possible.
  • Editing of user-defined fields after the request is closed – when this setting is enabled, it is possible to edit values in user fields even after the request is closed
  • Allow Company changes at any time – after enabling this setting, it is possible to change the Company at any time for which the request is registered
  • Request weight – when enabled, the Request Weight field appears in the request form, allowing requests to be sorted independently of other criteria. Decimal numbers can also be entered into the field, making sorting more flexible. Access to this field is controlled by user permissions.
  • Automatic deal selection on a request – when enabled, an deal is automatically added when creating a request if exactly one deal is currently registered for the company in the system
  • Copying requests to companies – when enabled, a selected request can be copied to multiple companies
  • Option to quickly close a request – when enabled, the Close Request button is available. The button is only visible to those assignees who have permission to close the request.
    • Offer the option to block notifications – when closing a request via the quick close button, there is an option to block the notification. Blocking is only offered if change of status notification is set to “completed” in the Global Settings → Notifications → Basic Settings → section CDESK Notifications → Request Status Change → Status Change “completed”
  • Close an item with a single click in the lists for Requests, Tasks, and Work Deals – when this option is enabled, a button to close the record appears in the corresponding row in the list of requests, tasks, and work deals without the need to open the record details and manually change the status
  • Automatically preset the company in a new request based on the search string – after searching the list of requests by company name and subsequently creating a request, the system automatically searches for the company based on the entered name; if there is only one result for the entered term, this company is automatically preset in the form for the new request
  • Extended request header – when enabled, basic information is displayed at the top of the open request details (below the number and name) for quick orientation within the request information. The displayed information can also be edited in this section.
  • Automatic filling of the request name – when enabled, the request name is automatically generated based on the first N characters of the request description. The name is generated only if it is not entered by the user creating the request.
    • Maximum number of characters for automatic name generation – specify the number of characters (N) from the description that will be used to generate the name
  • Automatic filling of the request name using AI – when enabled, the request name is automatically generated based on its description using AI, with a maximum length of N words. The name is generated only if it is not entered by the user creating the request.
    • Maximum number of words for automatic request name generation – specifies the number of words (N) from the request description that will be used to generate the name

Custom request codes

In this section, you can configure settings for and custom request codes. These settings cannot be used simultaneously with the request code field; therefore, they are only available when the option is disabled. The request code field in the General Settings section.

First, you need to enable the Custom codes functionality by toggling the corresponding switch. Once enabled, the Code scheme section will become available, where you can configure custom numeric codes for requests. The request code consists of prefix and value, where you can use a numeric value of various combinations of available codes or any constants. You can add a variable to the schema by clicking the + button in the Code Schema section and selecting the desired variable. Clicking the Refresh button resets the configured code to its original settings.

Image: Global settings for Custom Request Codes

Available variables for code schemas:

  • number – request number; the default length is 4 characters, but any number of characters can be entered. The number of characters for the request number must be specified in the section Code schema.
  • year – the year in which the request was created
  • project code – the project code associated with the project deal to which the request is linked
  • project deal code – the project deal code associated with the request
  • deal code – the deal code associated with the request

You can select any number of variables, which can be separated by various delimiters, such as the “-” character. You can change the order of the variables by dragging a variable to the desired position. The right-hand side displays a preview of Code examples based on the specified code scheme and the latest records in the CDESK system.

Separate number series

In this section of the settings, you can configure separate request number ranges. These settings cannot be used simultaneously with custom request codes; therefore, they are available only when the option Custom Codes is disabled in the section Custom Request Codes.

First, you need to enable the Separate Number Series feature by selecting from the available options. Number series can be applied to:

  • Request type
  • Request category
  • Level 1 area

After selecting one of the available options, a table will appear showing the currently defined prefixes, along with a button for defining a custom prefix. Each number series must be assigned a unique prefix. A change to the prefix applies to all requests. This is followed by a list of values for the selected number series type, where any of the defined prefixes can be assigned to each value. Request numbers created by this rule replace the system numbering.

Figure: Global settings for separate request number series

Discussion and email requests

In this section, you can configure whether the discussion and ext-mails functionality will be enabled in requests. You can also define templates for discussion posts and ext-mails. The specific available settings are:

  • Discussion in the request – when enabled, the functionality Discussion is available in the request, which you can use to communicate with the customer or internally among request assignees. The discussion is accessible from the list of requests or in the request details, on the tab Discussion.
  • Enable search in discussion posts – when enabled, using the search in the list of requests will also search for the entered term in the text of discussion posts
  • Ext-mail – when enabled, the functionality Ext-mail is available in the request, a simple email client for external communication regarding the request. This functionality is available in the request details on the Ext-mail tab.
  • Enable search in ext-mails – when enabled, using the search in the list of requests will also search for the entered term in the text of ext-mails
Image: Global settings for discussion and ext-mail in the request

If you use a clearly defined format for communication, or if certain types of responses and questions recur, you can create templates for discussion posts and ext-mails. Using templates ensures a consistent communication style and also makes it easier—and, above all, faster—to respond to individual posts.

To define a new template, click the button Add below the list of templates in the settings section Discussion and ext-mail requests. After clicking, a modal window will appear with a form for creating a template. The form contains the following fields:

  • Name – brief description of the template
  • Type – specifies the template type; the type determines the type of post to which the template can be applied. A single template can be assigned multiple types. The following options are available:
    • With customer – the template can be applied in a discussion post with a customer
    • Internal – the template can be applied in an internal discussion post
    • Ext-mail – the template can be applied in ext-mails
  • Description – the text of the post, which will be automatically filled in after applying the template to the post. The text can be formatted as desired and may include an image or attachment.
Image: Creating a new template for a discussion post and an ext-mail

To create a template, click the button Save. Once created, the template appears in the template table and is also available for selection in the field Template when creating a discussion post or an ext-mail.

Request deadlines

A ticket may have multiple deadlines associated with it, which determine the deal in which tickets are processed. In most cases, these deadlines are based on the established SLA. You can define which deadlines are associated with a ticket within the settings in this section of the global ticket settings. Settings for request deadlines include the following parameters:

  • Entering a response deadline – allows you to record a response deadline when submitting a request. You can also set whether this value is required or optional. Access to this field is controlled by user permissions.
  • Change Assignee After Response Deadline – when enabled, a field will appear in the request form where you can enter an alternate assignee. The selected assignee will be responsible for resolving the request if the primary assignee misses the response deadlines. Enabling this feature also makes the field for setting the resolver after a missed response available in the request template.
  • Setting the deadline for assigning a resolver – the option to record a deadline by which the request must be assigned to a specific resolver. The value of this field can also be marked as required.
  • Entering the completion date – option to record the date by which the request must be fulfilled. The field can be marked as required.
  • Option to define a completion date range – when this option is enabled, the fields From and To will appear in the request form next to the completion date. Allows you to specify the start date for when the request should begin to be addressed. This time period is also displayed in the calendar. This field can be marked as required; if the request is linked to a project deal, this field is automatically required.
  • Entering the deadline for an alternative solution – when this toggle is enabled, a field for the deadline by which an alternative solution must be delivered is added to the request’s deadlines. The value of this field can also be set as required.
  • Record Desired Deadline – when enabled, a desired deadline is also added to the tracked deadlines of the request. This is the deadline by which the customer wishes the request to be fulfilled. If this deadline is earlier than the fulfillment deadline, it is up to the assignee to decide whether to shorten the fulfillment deadline as well. If this date is later, the fulfillment date will be automatically adjusted according to the desired fulfillment date. Access to this field is permission-controlled for users. Filling in this field may be mandatory, optional, or custom, allowing you to set the request to fill it in based on individual request types.
  • Enable setting fixed deadlines – when this option is enabled, the deadlines on the request will be fixed, meaning they will not be moved (changed) even if the SLA settings would otherwise require it. In practice, this means that, for example, a request in the waiting for the customer status usually has its completion deadline postponed, as a response from the customer is awaited. With a fixed deadline, however, the completion deadline will not change, and the request may thus fall into arrears even though the responsibility now lies with the customer.
  • Recalculation of deadlines after changing an SLA parameter – when enabled, SLA deadlines are recalculated if any of the data used to determine these deadlines changes in the request. For example, a change in priority, request type, or service area.
  • Entering Deadlines in the Past – When enabled, it is possible to enter a deadline in the past, which may result in automatic failure to meet deadlines.
Image: Global settings for Request deadlines

Request priorities

This section contains settings related to request priority along with options for defining them. Request priority indicates how quickly a request needs to be resolved and has a direct impact on the calculation of individual deadlines. The following options are available within the settings:

  • Setting priority based on Urgency and Impact – when enabled, the fields Urgency and Impact will be displayed for selected request types. Priority is determined based on the urgency and impact specified in the request. The system automatically includes 4 predefined urgencies and impacts, which you can edit as needed or create additional ones. The urgency is specified by the customer when creating the request. The impacts are determined by the request assignee. The rules used to determine priority are defined in , in the matrix under the section , Request Impacts. Access to this field in the request form is permission-controlled for users.
    • By request type – clicking the gear icon displays a list of registered request types in the system, with the option to enable or disable the entry of urgency and impact when creating a request.
Figure: Matrix for determining priorities based on urgency and impact
  • Editing urgency after creating a request – when enabled, the selected urgency value can be edited even after the request has been created
  • VIP service – when enabled, it will be possible to set a higher priority than the one defined by default in the system. To use this feature, the request submitter must have the option enabled: VIP service in the user account (Users and Groups → Users user details tab General Information → section User Information). The priority adjustment will apply to requests that have request type and service area according to the settings in the other fields (listed below). The request priority will change if a VIP user is specified in the field Who is requesting or For whom is requesting.
    • VIP request priority – specifies by how many levels the request priority will change when using the VIP service. The available values are:
      • No change in priority (default) – the request priority will not change, but a VIP flag will be displayed in the request form
      • Increase priority by 1 level
      • Increase priority by 2 levels
      • Increase priority by 3 levels
      • Highest priority
    • VIP service by request type – option to limit the priority change to selected request types only
    • VIP service by request service area – option to limit priority changes to selected request service areas
  • Display information about the SLA used – when enabled, an icon appears next to the field name priority in the request form and; clicking it displays the SLA details used to determine the request priority

The default settings for the priority list are as follows:

  • 1 – emergency (SMS)
  • 2 – urgent (SMS)
  • 3 – standard
  • 4 – service
  • 5 – next inspection
  • 6 – long-term

Priorities can be freely modified—you can edit the name, order, and icon, and add translations for other language versions of the system. A priority marked as Default (in the Default column) is automatically set when creating a new request. Priorities that you do not need can be disabled in the Status column by toggling the switch to the “Off” position. You can define a new priority by clicking the Addbutton below the list of priorities and filling in the relevant information.

Image: Global settings for Request priorities

For new requests with priority 2 – urgent or 1 – emergency, it is also possible to send an SMS notification, which notifies the assignee(s) via an SMS message and/or a push notification in the mobile app. SMS notifications must be enabled via the settings at Global Settings → Connectors, API. Sending SMS or push notifications is enabled/disabled in the notification settings at Global Settings → Notifications and User Profile → Notifications. If you use a cloud service and select the server setting within the SMS gateway settings at Connectors, API, SMS services will be sent and billed as part of the CDESK system usage fees. If you choose custom settings, you will enter your details for the SMSBRANA.CZ SMS gateway, and you will pay the costs for sending SMS messages yourself.

Items from the CMDB

This section contains settings related to the use of items from the configuration management database (CMDB) in a request. The settings include the following options:

  • Selecting items from the CMDB – when enabled, a button for adding items (CIs) from the CMDB will appear in the request details. Items from the main groups and types that you specify in the settings below and that are linked to the selected request company will be available for selection. This functionality is permission-based for users.
  • Simplified selection of items from the CMDB – when enabled, the advanced filter for searching items from the CMDB is hidden in the request. Only a search field without filtering options will be available, and it will not be possible to select columns.
  • Allowed items from main groups and types – with this setting, you specify which main groups and types will be used to offer CI items in the request. Main groups and types must first be defined in the CMDB. The following main groups are available for selection: Devices, Service Catalog, Operations, Locations and General Category. To filter by type, you must first select a main group and then select the desired types belonging to that group. Without selecting a type, all items belonging to the entire group will be available in the request, without any type restrictions.
Figure: Filtering CMDB items by groups and types
  • SLO / Service Availability – When enabled, the service availability will be calculated for the service assigned to the request. It will be possible to record the actual start and end times of a service outage for the service from the CMDB configuration database.
  • Display service availability – monthly or annual service availability in percentages, displayed in the request details
  • Service selection on a request – permission to add items to a request that belong to a group in the CMDB configuration database Catalog of operated services. This feature is active only if the option SLO / Service Availability is enabled. When setting the option Optional or Mandatory, it will be possible to select services for all request types regardless of the settings in the section By Request Type. The settings by request type will be applied when selecting the value Custom.
    • By request type – for each request type, you can set whether the service selection will be mandatory, optional, or disabled. For each request type, you can also enable the display of service availability metrics. This setting applies if you select the option Custom when setting the scheduled start time.
  • Default setting for ’Affects service availability’ – determines the default state of the switch Affects service availability to on or off when entering a request that affects service availability. The switch is displayed only if this setting is configured for the given request type.
  • Automatic CI selection by service area – when enabled, the Service areas tab becomes available for a configuration item (CI) from the configuration management database (CMDB) belonging to the main “Services” category group. Settings can be configured on this tab. To automatically add this service to a request if a specific service area is set on the request. A service added in this way can only be removed from the request by changing the service area on the request.
  • Display a warning about an existing request for an item – when enabled, if a request is created with an item for which other open requests are already recorded, a warning about existing requests will be displayed

Reasons for closing the request

Through the settings for request termination reasons, you can configure a list of values that will be available in the request details when the status is changed to Completed. The termination reason is used for service management and for categorizing individual requests. The settings include the following options:

  • Entering the reason for closing a request – specifying whether entering a reason for closing is required when switching a request to the status Closed. If the value is set to Required or Optional, the field for the reason for closing will be displayed in every request. When selecting the option Custom, the settings will be based on the request type.
  • By request type – clicking the icon displays a list of defined request types with the option to specify whether filling in the field termination reason will be mandatory, optional, or disabled for that request type.

The system automatically includes predefined termination reasons for requests, which can be freely modified—you can edit the name, reorder them, add translations for other language versions of the system, and specify whether a given termination reason affects service availability. A termination reason marked as Default (in the column Default) is automatically preset when the request is switched to the status Completed. Termination reasons that are unnecessary for you can be disabled in the Status column by switching the toggle to the “off” position (the termination reason cannot be removed from the list). You can define a New termination reason by clicking the Add button below the list of reasons and filling in the relevant details.

Image: Global settings for reasons for closing a request

Methods for resolving requests upon closure

Using the settings of resolution methodswhen closing a request, you can configure a list of values that will be available in the request details when the status is changed to Closed. The settings include the following options:

  • Resolution methods when closing a request – specifying the request to enter a resolution method when closing a request (change of status to Closed). When setting the value Required or Optional, the resolution method field will be displayed in every request. When selecting the option Custom, the settings will be based on the request type.
  • By request type – clicking the icon displays a list of defined request types with the option to specify whether filling in the field solution method will be mandatory, optional, or disabled for that request type.

The system automatically includes predefined methods for resolving requests that can be freely modified—you can edit their names and order, or add translations for other language versions of the system. The resolution method marked as Default (in the Default column) is automatically set when a request is switched to the Completed status. Methods that are unnecessary for you can be disabled in the Status column by switching the toggle to the off position (the resolution method cannot be removed from the list). You can define a new resolution method by clicking the Add button below the list of methods and filling in the relevant information.

Figure: Global settings for resolution methods when closing a request

Reasons for the request

Through the request cause settings, you can set up a list of causes from which the request assignee can select the cause why a given request was submitted. The settings include the following options:

  • Request reason selection – specifies whether entering a request reason is required. When setting the value Required or Optional, the field for the reason will be displayed in every request. When selecting the option Custom, the settings will be taken into account according to the request type.
  • According to the request type – after clicking on the icon , a list of defined request types will be displayed, with the option to specify whether filling in the cause field for a given request type is mandatory, optional, or disabled.

The system automatically has predefined causes for requests, which can be freely modified—you can edit the name, change the order, add translations for other language versions of the system, and specify whether a given cause affects service availability. A cause marked as Default (in the column Default) is automatically preset after a request is created. Causes that are unnecessary for you can be disabled in the Status column by toggling the switch to the “off” position (the cause cannot be removed from the list). You can define a New request cause by clicking the Add button below the list of causes and filling in the relevant information

Image: Global settings for Request reasons

Message for the new assignee

In the settings section for Messages for new assignee, you can define the dropdown options that will be available in the “Message for new assignee” field if a change of assignee is requested. To use this feature, the toggle switch must be set to the “On” position. The selected item from the dropdown list will be inserted at the beginning of the message subject with a notification regarding the request.

The system automatically has predefined messages for new assignee of the request, which can be freely modified—you can edit the name, reorder them, or add translations for other language versions of the system. The message marked as Default (in the Default column) is automatically set as the default when the request assignee is changed. Messages that are unnecessary for you can be disabled in the Status column by toggling the switch to the “Off” position (the message cannot be removed from the list). You can define a New message for new assignee by clicking the Add button below the message list and filling in the relevant details.

Image: Global settings for messages for new request assignee

Default settings for the requests list

In this section of the settings, you can specify which columns and in what order will be displayed by default in the request list. You can also set different views for operators and assignees, as well as for other accounts. It is also possible to set default filtering for records.

To configure the display, click the gear icon in the field for which you want to configure the display (operators and assignees or other accounts). Using the gear icon in the last column of the list table, you can customize the column display by selecting which columns will appear in the list and specifying their order. You can also freely adjust the width of each column displayed in the list by clicking on the area between the columns and dragging it to the right or left to the desired width. You can save the selected order by clicking the “” button + above the list and entering a name for that layout.

Figure: Saving the column list view

You can also limit the records displayed by applying filters. To do this, use the advanced search filter, which you can access by clicking the button + next to the field Search. Depending on the column type, you can choose between “contains” or “does not contain” conditions for the search term or part of it; for dropdown lists, select one of the available values. You can freely combine and expand search conditions using the logical operators AND (and) and OR (or). If you set a filter, this filter will be automatically applied when displaying records in the list of requests. For successful configuration, you must use the Search button (for correct application of filtering).

When configuring the list for other accounts, you can allow users to reorder the columns by toggling the switch to the “On” position in the relevant setting.

Image: Global settings for the default request list configuration

Custom fields

In this section of the settings, you can assign defined custom fields that will be displayed on all new requests. To assign custom fields, click the Assign custom field button. After clicking, a modal window opens with a list of custom fields that you define under the CMDB module (CMDB → User-defined fields → Custom fields). Next to each property is a checkbox that you can use to select the desired property. Add the selected properties using the button Assign selected.

Figure: Assigning user fields to a request

If the list does not contain the property you need, you can also define it directly in the property selection window using the buttons +Simple Custom Field and +Composite Custom Field. By selecting the option +Simple Custom Field, you create a basic property. Use the button to add a compound custom field, which contains multiple basic properties. Working with custom fields is described in detail in a separate article User-defined fields.

The selected fields will be added to the Custom Fields list. The fields will appear in the request form in the same order as they are listed here. You can reorder the items by dragging the icon. To delete Custom Fields that you have already added but no longer wish to use, click the Delete button, which you can find in the context menu in the row of the relevant field. Using the Edit button in the context menu, you can edit the values of the given field.

Above the list is a search bar that makes it easy to quickly find a specific field. There are also buttons here for customizing the list view. If the list of custom fields in the request is too long and no further property configuration is needed, you can use the Field placement option. Checking this option hides the settings and displays only the field names and the icon for changing the order. Checking the option List of settings displays a detailed list of settings for individual custom fields again.

Figure: List of user fields on a request – Field layout
Figure: List of user fields on a request – List view with settings

You can customize each of the custom fields assigned to the list as you wish. The following options are available:

  • Show collapsed – if this option is checked, the entire field will not be displayed in the request form; only the checkbox will appear. The field will expand when this checkbox is selected.
  • Required Field – When the Required option is checked, the field will be marked as required in the request form. You will not be able to save the request unless you fill in the field.
  • Multiple Values – when this option is checked, you will be able to fill in the field multiple times. Selecting this option makes the Limit field available, where you can limit this number.
  • Subject to Approval – allows you to set approval for selected custom fields – the value of this custom field is subject to an approval process. We cover the topic of approval via custom fields in more detail in the section Using dynamic approval via custom fields.
  • Show in the list of requests – checking this option allows you to display the given custom field as a separate column in the list of requests.
  • Editing during approval – allows you to edit the value of a custom field during the request approval process.
  • Pre-fill – allows you to define a value that will be automatically pre-filled when opening the form to create a new request.
Image: Display of user fields in the request form

Bulk editing of request fields

In this section, you can select the fields that can be edited when using or the bulk request editing feature at. Only fields with the toggle switch set to “On” will be editable. Fields with editing disabled will not appear in the list of data available for editing. The following fields can be configured:

  • Due Date
  • Service Area
  • Request Type
  • Status
  • User or User Group
  • Assisting Assignees
  • Priority
  • Impact
  • Cause
  • Resolution

In the settings, you can also specify the default setting for blocking notifications, which determines which notifications will be blocked when data is changed via bulk editing. This setting can be further adjusted during bulk editing of requests. You can block:

  • All notifications
  • Customer notifications
  • SMS notifications

You can edit multiple requests at once in the request list (Requests → Requests) by clicking the edit icon in the first column of the list.