CDESK 3.2.10 brings a significant shift in requirements and process management. The key innovation is the transition to systematic change and incident management – new requirement statuses, designation of change managers and better control of the process flow.
The version also includes requirements merging including discussion, expanded project management options, modifications in CMDB and Asset Records, improved approvals, notifications and mobile interface optimizations.
Article content
- Adding columns for the latest responses from the assignee and the requester
- Date of last response from the requester
- Last response from the requester
- Date of last response from the assignee
- Last response from the assignee
- Company selection in the Request Catalogue on the Dashboard
- Distinguishing between automatic and user-performed evaluation upon acceptance
- Adding filtering by record visibility
- Adding the Root Record column with the highest parent record of the request
- Enabling linking of requests from different companies
- Creating a project team assignee group for a project deal
- Displaying the hierarchy of project deals in the request detail
- Inheriting project manager, priority, and project team from a parent project order
- Adding prioritisation of project deals, including a new Priority column
- Requests created on a project deal inherit its Resolve From dates
- Requests created on a project deal inherit its planning mode
Merging multiple requests into a primary request, including discussion
In practice, it sometimes happens that when a fault occurs in the system, multiple users report it, resulting in duplicate requests. CDESK 3.2.10 allows duplicates to be removed by merging requests into one. By selecting multiple requests that meet the system constraints, you will see the option to merge these records into a single request.
After clicking the Merge option, you must choose the primary request, which will become the main holder of settings, and to which the selected requests will be subordinated. You can also merge:
- Request descriptions
- Request attachments
- Discussion posts
- Discussion recipients (who can be notified of the merge immediately)
- Linked configuration items
Merged requests are closed and moved to the archive. Requests closed in this way contain information about the merge in the header.
Improved management of change requests (new request statuses, designation of change managers, and more effective process control)
We have implemented several changes that strengthen control and risk management during changes. By adding these features, we are taking another step towards meeting the requirements of the Cybersecurity Act (ZoKB) for our clients and reducing the likelihood of inconsistent interventions in operations. Clear accountability and higher process discipline.
Request Manager
- The role is selected in the request template
- Has full access to the request (read, edit, delete), including requests in the For Review and For Evaluation statuses. The Manager is not affected in this case by permission restrictions in the user settings.
Request Type Manager
- Configurable per request type
- Has full access to requests of that type, regardless of permissions and statuses of those requests.
For Review status
- Activated automatically after submitting a request (if the feature is enabled)
- The request is locked; before further steps, the process must be approved by the Request Manager (or Request Type Manager)
- The status may be subject to SLA
For Completion status
- The manager can return the request to the requester for additional information
For Evaluation status
- Used before closing the request
- The request in this status is edited exclusively by the Request Manager
(or Request Type Manager)
For the purposes of change and problem management, we are expanding the notification model when reviewing requests.
Previously, when a request transitioned to the For Review status, there was no dedicated notification event. All notifications at this point fell under the New Request event, which did not allow targeted notification of the managers responsible for review.
A new dedicated event – Request Review – is now available, within which it is possible to:
- notify the Request Manager and Request Type Managers (primary purpose)
- optionally include other roles, as with other request notification events.
At the same time, the logic of a “new request” is adjusted:
- a request is not considered new at the moment of creation
- it is only considered new from the moment it enters resolution, i.e. after review or approval.
This adjustment allows for a clear separation of the review phase from the actual resolution and more precisely targets notifications to the responsible persons.
General Functions
Central search extended to include closed objects from the last 14 days
With version 3.2.10, the central search includes not only open objects but also those that have been completed or closed in the last 14 days.
This is only a change in the search conditions – it has no impact on the usual filters in the lists and does not slow down the system unnecessarily.
Requests
Adding columns for the latest responses from the assignee and the requester
The aim is to identify requests that require a response. Typically, this involves situations where the assignee needs to reply to the last response from the customer or end user – so that no unanswered customer posts remain in requests. It is also important to be able to verify whether the customer has responded to the assignee’s reply. To support this way of working, filterable and sortable columns have been added to the request list that clearly express these statuses and enable more efficient support organisation.
Four new columns have been added to the request list:
- Date of last response from the requester
- Last response from the requester
- Date of last response from the assignee
- Last response from the assignee
Column values are continuously filled in and cleared based on the actions described below. From a deadline perspective, always focus on the main date columns, such as Response Deadline and Completion Deadline, especially if all 4 columns are empty.
Date of last response from the requester
Displays the date and time of the last action by the customer that requires a response from the assignee. This includes:
- Creation of a new request in the Received status
- A discussion post added by the requester
- A status change back to In Progress
This column is only visible to assignee and administrator accounts. The date and time shown in the column is cleared when an assignee response occurs on the request.
The Date of Last Response from the Requester/Assignee columns will remain empty if the request status is Waiting for Customer, Testing by Customer, Deployment Activities, Deferred, Pending, or Offer.
Last response from the requester
The column contains the content of the customer’s last response, for example a discussion post or a status change. Hovering the cursor over it also displays the change detail with the name of the user who made the change. This column is visible only to assignee and administrator accounts.
Date of last response from the assignee
Displays the date and time of the last action taken by the request assignee. This includes:
- Adding a post to the customer discussion
- Changing the request status
This column is visible to all authorised users regardless of their role.
Last response from the assignee
Provides a textual description of the last action performed by the assignee (adding a discussion post, changing the status). Hovering the cursor over the text displays the action detail along with the name of the assignee who made the change. This column is visible to all users regardless of role.
Company selection in the Request Catalogue on the Dashboard
The Request Catalogue widget on the dashboard now includes the option to switch the company for which the catalogue is displayed.
By default, the widget displays tiles for the company set in the user’s profile (or the first assigned company). This company is also pre-selected in the selection field. If the user has permission to submit requests on behalf of multiple companies, they can manually change the company. After the change, the list of tiles is automatically refreshed to correspond to the catalogue available for the selected company.
This change reflects the way request templates work, which may be made available only to selected companies.
Distinguishing between automatic and user-performed evaluation upon acceptance
We have added a distinction to the Rating column for requests that were automatically closed after the set deadline elapsed.
In the case of automatic closure of a request:
- The value “Automatically” will be entered in the Rating column.
- The system also allows a different value to be used, if one is defined for automatic closure of the request.
Requests can be filtered by this value.
Adding filtering by record visibility
Request lists can be filtered by the “Visibility” parameter (internal and standard requests).
Adding the Root Record column with the highest parent record of the request
A Root Record column has been added to the request list. If a request has a parent record, this column displays the highest one in the hierarchy. This may be a parent request, a project deal, or a project.
The column contains the code and name of the parent record, as well as the option to navigate directly to the record details.
Enabling linking of requests from different companies
In CDESK, we have adjusted the way linked requests are handled so that it better meets the actual needs of users and their permissions.
Users can now create and link related, parent, and child requests without restriction to the company set on the parent request. When creating a new linked request, the company is inherited by default, but the user can change it as needed.
Configuration Database
Simplified management of structure and records
We have modified several details to make it easier to create new CIs and sort them into groups and types.
At the group level, immediately after clicking the hamburger icon, the following options are available:
- Create group
- Create item type
- Delete group
- Edit group details
At the item type level:
- Add item
These actions are available directly from the context menu, without having to navigate into record details.
Adding a display of active items
By clicking the button, you can filter out all inactive and non-archived items, so that the list displays only those that are actively in use. This feature can also improve performance when working with items.
Fulfilments
Four columns added to the fulfilment approval list
We have added the columns Fulfilment Date, Invoiced Amount, Actual Time Worked and Deal Code. Users can add and remove these columns, and they can also be included in exports, and it is possible to filter by them.
The display of internal fulfilments can be toggled on and off in the list
In the Fulfilment List and the Fulfilment Approval List, we have added a checkbox that toggles the display of internal fulfilments on and off. Disabling the display will prevent internal fulfilments from being added to exports.
Editing actual time worked in billing fulfilment
If the actual time worked on a billing fulfilment consists of exactly one internal fulfilment, it will be possible to edit it via the billing fulfilment form.
Transfer of actual time worked to billing fulfilment time
When entering a time value in the Actual Time Worked field, the Billing Time of the fulfilment is also automatically synchronised. This applies to both simplified entry and when marking a time range.
Asset Management
Adding a tree structure to Asset Management
With the new version, the tree structure from the CMDB is also transferred to Asset Management. This structure is also present during inventory, specifically when selecting an asset and a location.
Adding a Handover Protocol Status Column
We are adding status indicators to the handover protocol list module, so that the status of the protocol and whether it has been signed is clearly visible directly from the list.
Previously, the status of a handover protocol was not tracked separately, which made quick orientation difficult – particularly distinguishing between signed and unsigned protocols.
A new Status column has been added to the handover protocol list, based on the actual signing process:
- In preparation – the handover protocol has been created, but signing via CDESK has not been activated
- Pending signature – signing via CDESK is activated, but the protocol has not yet been signed by either party
- Partially signed – the protocol has been signed by one of the parties
- Signed – the protocol has been signed by both parties
For better clarity, we have also added a visual indication directly in the list. In the Transferor and Transferee columns, a green ✓ symbol appears next to the user’s name after signing, indicating that the respective party has already signed the handover protocol.
Adding a column with the last change on an asset in the asset list
We are adding a Last Change column to the asset list, which will provide an overview of what was last changed on the record and when the change occurred.
The column is conceptually the same as in the Requests module but has been extended with date information so that records can be filtered and sorted by it. The aim is to quickly identify assets on which the last modification occurred, without needing to open the record detail.
Extension of central search to include device serial numbers in requests
We have added the ability to search by the serial number of a device linked to a request via stock item cards through the Device Repair extension to the central search.
Searching by serial number is available under the following conditions:
- The Device Repair extension (request type) is activated in the environment
- The user searches specifically within requests using the shortcut cdr, followed by the device serial number or part of it.
While typing, the dropdown list displays results only from open requests, so that active records are offered first. After confirming the search with the Enter key, it is possible to extend the search to closed requests as well, by enabling the relevant checkbox.
Projects
Creating a project team assignee group for a project deal
Project requests now include the option to automatically work with the project team as an assignee group. The aim of this adjustment is to simplify the allocation of assignees and to ensure that all members of the project team on the project deal are consistently offered as assignees for related requests.
The mechanism is available only if the project team on project deals is enabled in Global Settings.
- A new option — Project Team — has been added to the Give Preference to Assignee field in the request template.
If a request is created from a template with this option and is linked to a project deal, the Project Team is automatically set as the assignee group. - For each project deal that has a defined project team (at least one assignee), a virtual assignee group is dynamically created (named Project Team + project deal code and name).
- This functionality applies to requests directly linked to the project deal, as well as to child requests under that deal.
Displaying the hierarchy of project deals in the request detail
The Project Deal field on a request now displays the hierarchical arrangement of project deals.
The hierarchy is displayed from the nearest (current) record upwards, i.e. from left to right to the highest (root) record. The individual levels of the hierarchy are separated by the “›” character.
Inheritance of project manager, priority and project team from the parent project deal
We have added a mechanism to project deals for inheriting the project manager, priority, and project team downwards to child project deals. The aim is to unify behaviour within the project hierarchy and reduce the need for manual configuration of the same values at multiple levels.
Adding prioritisation of project deals, including a new Priority column
We now allow priority rankings to be created and set for project deals. Their list, with the option to create new levels, is in Global Settings. Priorities can be set in the environment as an optional value, a mandatory value, or can be disabled (the default state).
Users are offered a pre-configured priority ranking which they can adjust, adding or removing levels, or changing their icons and names.
A Priority column has been added to the project deal list, by which it is possible to search and filter (values ‘is not / is’).
Requests created on a project deal inherit its Resolve From dates
When creating a new request linked to a project deal, we have adjusted the pre-filling of deadlines.
From version 3.2.10, if a user creates a new request and assigns a project deal to it during creation, the Resolve From field is automatically set to the current date and time. The aim is to ensure consistent planning completion for project requests and eliminate situations where the start of the deadline remained empty.
This adjustment applies only when creating a new request linked to a project deal. It does not apply to cases where the project deal is added subsequently to an existing request.
Requests created on a project deal inherit its planning mode
Previously, when a new request was created, the planning mode was automatically set to ‘Automatic’, regardless of the project deal’s settings. From now on, the default planning mode is inherited from the project deal to which the request is assigned.
Thanks to this adjustment, requests are aligned from the outset with the project’s planning logic, and there is no need to manually adjust the planning mode after the request has been created.
Approval
Adding column selection in the approval list
In the approval list, version 3.2.10 adds the option to select columns.
Implementation of open approvals indicator in the main menu
We have added an extension to the main menu for the Approval item, which provides an overview of pending approvals from the user.
The number of open approvals for the active user is now displayed next to the Approval label. The indicator is shown as a single number on a yellow background, analogous to the counter for requests, but without further breakdown.
Adding free approver selection as a step in predefined approval
The option for free selection of approvers has been added to the approval rule step. This can include:
- Approver groups
- Approvers from a group
- Approvers (overall)
When creating templates with such a predefined approval, it is possible to select anyone from the chosen group as an approver, or to mark the whole group directly, if it was added to the free approval as a group.
Notifications
Adding roles to notification sending rules – Followers, Added Followers, Removed Followers
We have added new roles to the notification sending rules for requests, which expand the options for addressing recipients.
The following roles are now available for each notification event from requests:
- Follower
- Added followers
- Removed followers
These roles work the same as in project deal notifications and allow you to more precisely control who receives a notification and when, depending on changes in the list of followers.
For rule-based notifications: Linking SMS templates to request templates and dynamic variables
Rule-based notifications are still in beta mode, but as several clients are already using them, we have included this item in the release notes.
For users with rule-based notifications enabled, SMS templates can be linked to a specific request template, which clearly determines their use for that type of request. This link is displayed directly in the SMS template detail and serves as a consistency control mechanism between the message content and the data from which it originates.
When selecting an SMS template in the request template, the user is only offered SMS templates linked to the request template or SMS templates without links.
SMS templates can also use dynamic variables from custom fields on the request template. The variables are displayed directly in the SMS template detail. When using these variables, the SMS template is automatically locked to the relevant request template to maintain data compatibility.
When sending an SMS notification, dynamic variables are automatically replaced with specific values from the request, ensuring an accurate and contextually correct message content.
Users and Groups
Addition of the Visible Companies column to the user list
We have added a new informational column – Visible Companies – which expands the overview beyond the existing Assigned Companies column.
This column displays all companies that have been manually made visible to the user but are not directly assigned. The column thus serves as supplementary information to the assignment and helps to clearly distinguish which companies the record is visible to beyond the explicit assignment.
Filtering permissions: Displaying all allowed and denied permissions
We are adding a new display filter to the permissions tree (for both groups and users) that will allow permissions to be quickly filtered by setting type and resulting status.
The filter will be available as a dropdown next to the search field and will have the following modes:
- All (current behaviour, remains default)
- All explicitly enabled (solid green marking)
- All explicitly disabled (solid red marking)
- All inherited (faded marking)
- All inherited, enabled (faded green marking)
- All inherited, disabled (faded red marking)
The aim is to simplify navigation in extensive permission trees and enable quick checking of which rights are set directly (explicitly) and which result from inheritance, including the distinction between enabled and disabled permissions.
ERP Integration Connector
Support for composite stock cards (sets) in integration with Money S4
We are expanding the CDESK integration with the Money S4 accounting system to support composite stock cards (sets). This adjustment unifies the way stock items are handled between the two systems.
- CDESK can now retrieve composite stock cards (sets) from Money S4 and work with them directly in requests.
- When sending an order from CDESK to Money S4:
- composite stock cards are not sent as a single item
- only individual stock cards that make up the given set are transferred to the order.
CM Integration
Automatic insertion of remote access into a request based on the requester’s email
A block with remote access to the computer is automatically inserted into the request based on the match between the submitter’s email and the registration data in C-Monitor. The search is restricted to the company of the request.
