Beta verzia novej dokumentácie.

Working with an existing request from the assignee’s perspective

All requests, regardless of how they were created, are available at Requests → Requests. You can search, filter, configure diagrams, and perform other actions on the records.

Double-clicking, or clicking on the request name, clicking on the context menu ‘’ and selecting the required action in the request row, or using the right-hand panel ‘’, will open a window with a form similar to that used when creating a request. The options viewed depend on the type of access and the level of permissions assigned to the user. The topic of visibility and permissions for accessing requests is covered in detail in the documentation section ‘Permissions and Access to Requests’.

If you leave the system in its default state, from the operator or assignee role, you can perform the following operations on an existing request:

  • editing a request (changing the status, assignee, requester, deadlines, …)
  • discussion with the customer and internal discussion
  • communication via ext-mail
  • adding quotes to a request
  • adding and recording purchase orders for a request
  • adding tasks to a request
  • adding work purchase orders to a request
  • adding billing and internal fulfilment of a request
  • adding links to other requests
  • recording planned work
  • account for a request
  • managing notifications for a request
  • trackingtrack request history

The Assignee and Status of the request fields in the Basic Information section are of fundamental importance for working with a request, as they affect the fulfillment of the deadlines defined in the SLA. A more detailed description of individual actions can be found in separate sections of the manual, where you will learn detailed information about basic actions as well as specific actions you can perform on a request.

Edit Request

Editing a request and working with a record begin with a basic step: opening the request detail. This applies whether the request you wish to work on is available in the widget on the Dashboard, or whether you are viewing the list of requests directly. Some fields can also be edited directly from the list of requests, e.g. status, priority or assignee. To edit fields directly in the list, click on the cell containing the value you wish to edit and then select from the available options.

Figure: Example of editing the ‘Status’ value directly in the list of requests

Depending on the system configuration, it is only possible to edit the details of a request once it has been assigned to a specific assignee. By enabling the ‘Edit request before assignment’ settings, the request can be edited immediately after its creation. It is also possible to explicitly allow editing of specific data (e.g. the ‘Company’ and ‘Description’ fields, etc.) – the individual settings of the request module are covered in detail in the ‘Basic Settings’ section of the documentation. If you are not the assignee for the request, editing the fields in the form will be unreachable. Once you have taken on the request, you will be able to edit the fields.

Change of assignee and the person who submitted the request

Changing the assignee involves selecting a specific CDESK user with the appropriate permissions to act as the assignee for the request in question. Only those users who meet the criteria set out in your CDESK system configuration are available for selection. If a request is assigned to a group, a user belonging to that group can take over the request for resolution simply by clicking the ‘Assign to me’ option, either from the list of requests or directly within the request detail. If you wish to change the assignee – for example, from a managerial position – you can do so by simply clicking in the ‘Assignee’ field, selecting the required assignee and then saving the changes. The new assignee will be notified of this change.

Once a request has been assigned to a specific assignee, almost all fields on the form become editable, with the exception of ‘Company’ field (‘Company’ field can be edited if the ‘Allow Company changes at any time’ settings are enabled) and the ‘SLA’ field. If, under Global Settings → Requests → Basic Settings, the option to edit a request before it is assigned is disabled, for a request where only the assignee group is set (i.e. the request is in ‘Received’ status), only ‘Assignee’ field can be changed. This applies only when the ‘Restrict resolver selection by assignee group’ function is enabled. If this function is disabled, the request is editable immediately after saving.

Deadlines on a request may be editable depending on the settings for rescheduling in the SLA applied to the request. The SLA allows you to specify who can reschedule dates and at what priority level.

Change of request status

Request statuses can be configured under Global Settings → Requests → Request Statuses. Specifically, you can enable and use up to 26 different statuses for open requests, 30 custom statuses for open requests and 7 completion statuses. Further information on the meaning of individual statuses and how to edit them is available in the Request Statuses section of the documentation.

The following list shows the available request statuses; the highlighted statuses represent the basic statuses which cannot be disabled and which also affect the calculation of dates:

  • Received
  • waiting for approval
  • assigned
  • authentication by the responsible person
  • offer
  • awaiting customer
  • Accepted by customer and sales organisation
  • ordered
  • start of implementation of realization
  • pending assessment
  • Work in progress on NR
  • Completion
  • in progress
  • awaiting the third party
  • being handled by a subcontractor
  • deployment activities
  • on hold
  • Following contact will occur shortly
  • in stock
  • internal testing
  • tested by the customer
  • claim
  • postponed
  • provided to the National Council
  • accepted by NR
  • pending assessment
  • Carried out
  • Completion
  • completion accepted
  • completion without acceptance
  • denied
  • partial answer
  • full answer

To change the status of a request, select the required status from the Status field, which is located in the top information bar or directly within the request form. Confirm the change of status by clicking the Save button.

Figure: Change of status for the request

Change to the request deadlines

For each request deadline, the time remaining until the deadline is counted down. Once the deadline is done, the countdown stops and a check is carried out to see if it was done on time. For certain statuses, it is possible to stop the countdown. If the date has been met, a tick is viewed; if the date has been exceeded, an exclamation mark is viewed.

Each request has a response deadline and a completion deadline set; depending on the settings, optional dates may also be viewed and counted. The countdown and assessment of whether individual dates have been met are governed as follows:

  • Assignment deadline (1) – the countdown stops when a specific assignee is assigned to the request; if a new request has been assigned to a group of assignees, the countdown stops. For a request assigned to a specific assignee upon its creation, the countdown does not take place and the deadline is selected as done
  • Time to Alternative Solution (TTAS) – the countdown stops when the request’s status is changed to ‘Alternative Solution Provided’
  • Response deadline – the countdown stops upon one of the following changes to the request: a status change, the addition of a discussion post to the discussion with the customer, or the addition of a fulfilment
  • Start date (1) – allows a date to be recorded on the request from which the request is to be resolved
  • Completion date – the countdown is paused when the request status is changed to ‘Completed’
  • Desired date – the date to which the client wishes the request to be completed. If this date is earlier than the completion deadline, no change is made to the request and it is at the discretion of the assignee whether to bring forward the completion deadline. Conversely, if this date is later than the completion deadline, the completion deadline will be automatically adjusted to match the desired date of solution.
Figure: Dates on the request

(1) Optional dates – response deadline, time to own, alternative solution deadline, fulfilment deadline from, and desired date are viewed if they are enabled in Global Settings → Requests → Basic Settings, In the Request Deadlines section, and the ‘Count request deadlines’ option is enabled in the SLA section of the Company tab. These dates are viewed if they are enabled in the permissions (Requests → Access to fields → Response deadline, Time to Own, …).

Record of the solution and internal notes

The ‘Resolution’ field is used to record how a request was resolved, unless you are using ‘Fulfilments’. Fulfilments allow you to record the timeline of a request’s resolution, bill the company for the work recorded, and track internal time worked; we therefore recommend that you consider applying for fulfilments rather than the standard ‘Solution’ text field. The ‘Internal Note’ field is intended for internal lists, as it is not accessible to the customer’s account.

You can edit the ‘Solution’ and ‘Internal Note’ text fields as you wish on a saved request.

Figure: Solution and internal note on the request

Discussion in the request

The discussion forum is intended for communication between the client and the assignee, and amongst the assignees themselves. All posts are available on the ‘Discussion’ tab in the request detail (this tab only becomes available once a request has been created, and its visibility also depends on the authorization settings for the logged-in user). Posts are sorted from newest to oldest. The tick boxes above the list allow you to hide posts informing you of a change of status for the request.

Discussion with the customer

To add a post to a discussion with a customer, use the + Discussion with customer button.

Image: Button for adding a discussion with a customer to a request

Clicking the button will view a form for submitting a discussion post. The form contains the following fields:

  • To – a field for selecting the recipients of the discussion post. Recipients can be added manually, either by selecting from the list that appears when you click in the recipient field or by typing in an email address. Some recipients are added automatically. Recipients can be removed by clicking the ‘x’ icon next to the recipient’s name. A list of notification recipients is displayed below the field:
    • Automatically added – recipients are automatically completed according to the request notification settings; this includes the customer’s contact details, provided they have enabled notifications for requests
    • Manually added – a manually added recipient can be a user, a customer contact or an email address. These recipients are colour-coded to distinguish them from the automatically added recipients

All contacts set to receive notifications will also be notified of all following posts, unless they are removed from the list (by clicking the x icon next to the contact).

  • Template – the option to choose from predefined templates, which will be used to pre-fill the text of a discussion post. The request template must be defined in advance under Global Settings → Requests → Basic Settings → Discussion and Ext-Mail Requests section.
  • Message – a text field for entering the content of the post, with the option to format text and insert images or videos
  • File attachment field – on the right-hand side is the location for uploading a file, such as a screenshot or photograph. Clicking this field opens a dialogue box for selecting a file; alternatively, locate the file on your PC and drag & drop it into the field.
  • Signature – a field for selecting a signature to be appended to the end of your discussion post. The signature must be defined in advance in the user’s profile (under My Profile → the ‘Discussion Signature Settings’ section).
Image: Form for adding a discussion with a customer to a request

To post your message, click on ‘Post to discussion’. The ‘Preview discussion’ button allows you to preview the email or customer notification before sending it. Clicking on the ‘Hide post’ option (the ‘X’ button) will hide the post, which will remain saved as a draft. Clicking ‘Delete’ will permanently delete the post you have written. Selecting ‘Change to internal discussion post’ will change the post type and delete customer accounts from the recipients.

Internal discussion

To add a post to the discussion, use the + Internal discussion button.

Image: Button for adding an internal discussion to a request

Clicking the button will view a form for posting an internal discussion post. The form contains the following fields:

  • To – a field for selecting the recipients of the discussion post. Recipients can be added manually, by selecting from the list that appears when you click inside the recipient field, or by typing in an email address. Some recipients are added automatically. Recipients can be removed by clicking the ‘x’ icon next to the recipient’s name. A list of notification recipients is displayed below the field:
    • Automatically added – recipients are automatically completed according to the request notification settings; this includes the customer’s contact details, provided the customer has enabled notifications for requests
    • Manually added – a manually added recipient can be a user, a customer contact or an email address. These recipients are colour-coded to distinguish them from automatically added recipients

All contacts set to receive notifications will also be notified of all following posts, unless they are removed from the list (by clicking the x icon next to the contact).

  • Message – a text box for entering the content of the post, with the option to format text and insert images or videos
  • File attachment field – the location of the field for uploading a file is on the right-hand side, where files such as screenshots or photographs can be uploaded. Clicking this field opens a dialogue box for selecting a file; alternatively, locate the file on your PC and drag & drop it into the field.
  • Signature – a field for selecting a signature to be appended to the end of a discussion post. The signature must be defined in advance in the user’s profile (under My Profile → the ‘Discussion Signature Settings’ section).
Image: Form for adding a post to an internal discussion within a request

To post your message, click on ‘Post to internal discussion’. The ‘Preview discussion’ button allows you to preview the email notification before sending it. Clicking on ‘Hide post’ (the X button) will hide the post, whilst it remains saved as a draft. Clicking ‘Delete’ will permanently delete the post you have written. Selecting ‘Change to discussion post’ will automatically adjust the post type and the list of recipients.

Communication via ext-mail

External mail (Ext-mail) extends the communication options beyond the request to include communication with third parties in a manner similar to email. This functionality is available in the request detail on the Ext-mail tab, which becomes accessible once a request has been created; its visibility also depends on the authorization settings for the logged-in user. Communication can be divided into multiple threads according to your needs. Messages are sent only to the specified addresses; there are no pre-set recipients. Similarly, answers are sent only to the specified addresses within a given thread.

To create a new thread, click on the + New Ext-mail button. Once clicked, a form will be viewed with the following fields:

Image: Form for sending an ext-mail in a request
  • From – the name and email address of the sender of the external email. The field is automatically pre-filled with the name of the logged-in user and cannot be edited.
  • To – a field for entering the recipients of the external email. You can choose from users in the system, or manually enter a new email address (even one outside the CDESK system).
  • CC – a field for entering the email addresses of recipients to be included in the CC field of the external email (as with standard emails).
  • Subject – the subject of the external email. The field is automatically pre-filled with the request number and name, which can be edited.
  • Message – a text field for entering the content of the external email, with the option to format the text.
  • Signature – a field for selecting a signature to be appended to the end of the ext-mail. The signature must be defined in advance in the user’s profile (under My Profile → the ‘Signature settings for discussion requests’ section).
  • File attachment field – in this section, you can upload files to the ext-mail. Clicking on this field opens a dialogue box for selecting a file; alternatively, locate the file on your PC and drag & drop it into the field. You can also attach attachments from a request to an ext-mail – by selecting the relevant attachments in the ‘Attach files from request’ section of the form.

On the right-hand side of the form, there is a section for adding request attributes. By selecting individual parameters, the chosen attributes are completed in the body of the ext-mail, ensuring that the recipients of the message receive all the information they need. The following attributes can be added:

  • Request number and name
  • Description of the request
  • Company
  • Completion deadline for the request
  • Solution
  • Internal note
  • User-defined custom fields – clicking the + button views a list of user custom fields recorded for the request, from which you can select the fields to be included in the external email

To send an external email, click the ‘Send Email’ button. If you do not send the email you have composed, it will be saved as a draft. All emails recorded for a request are accessible on the ‘Ext-mail’ tab. All records are displayed, with the option to view only received or only sent external emails.

Posting offers

Registered offers may also form part of a request. The tab containing offers will only become available on the request once the request record has been created. The assignee can create a quotation, submit it for verification and then forward it to the client. The quotation becomes available to the client once it is set to ‘awaiting acceptance’ status, at which point the client will also receive an email notification. The customer response is then expected to include responses to the individual offer items.

To create a quotation, use the ‘+’ button next to the section name.

Image: Button for adding an internal discussion to a request

Clicking the button will view a form for creating an offer. The form is divided into two sections:

  • Basic details – basic details of the offer entered by the operator; the customer cannot edit these details.
  • Offer items – a list of offer items which the customer can approve or reject. An offer item can be added in three ways:
    • Free item – a freely created item with no relationship to other objects in CDESK.
    • Stock item – a link to a stock item recorded in the system.
    • Price list item – an item assigned from a predefined price list.
Image: Form for creating an offer in a request

You can create an offer by clicking the ‘Create’ button. Once created, the offer is automatically set to ‘In preparation’ status. To continue, you must first submit the offer for verification; once verified, the offer can be sent to the customer for acceptance. Detailed information on creating and working with offers can be found in the ‘Quotations’ section of the documentation.

Adding and tracking purchase orders

Within the ‘Orders’ section, it is possible to record received and issued orders on a request. The ‘Orders’ tab on a request becomes available only after the request record has been created. The list of recorded orders also includes a summary clearly showing the total value of all orders received and issued. All orders recorded in the request details are automatically available in the list of all orders under Documents → Order Register.

A purchase order can be recorded by clicking the + button next to the name of the relevant section (registered or issued orders).

Image: Button for recording an order in a request

When you click the button, a form for creating an order will be viewed. Detailed information on creating and managing orders can be found in the ‘Orders’ section of the documentation.

Adding tasks

Tasks allow a larger request to be broken down into smaller parts, which can be assigned to other staff members; they are simpler than work orders. The simplicity of tasks lies primarily in the minimal form. The tasks tab on a request only becomes available once the request record has been created (provided the Tasks module is enabled in Global Settings → Tasks).

A new task for a request can be created by clicking the + button next to the section name.

Image: Button for creating a task from a request

When you click on the button, a form will appear for you to fill in basic details such as the name or type of task, the assignee, the date from and date to, and so on.

Image: Task creation form

To create a task, click the Create button. Detailed information on creating tasks, the meaning of the individual fields and how to work with tasks is provided in the Tasks section of the documentation.

Adding work orders

Work orders provide a way of dividing up the work involved in a request. They are used to carry out the planned steps for a request and are generated automatically based on the request template. A work order can also be created manually – this option is subject to permissions.

Unlike Tasks, work orders affect SLA calculations and can be queued in a conditional serial-parallel manner. They can also affect the status of a request. For example, a request automatically changes to the ‘Completed’ status once all assigned work orders have been completed.

You can add a new work order to a request using the ‘+’ icon next to the section name.

Figure: Button for creating a work order from a request

Once you have clicked, a form will appear for you to fill in the details of the work order. As this is a manually created work order, it is not possible to select from pre-defined work order templates (this option is available when defining work orders in a request template).

Image: Form for creating a work order

To create a work order, click the ‘Create’ button. You can also import work orders into a request using the ‘Import XLS’ button (only lists of work orders in XLS format can be imported). You can export the current list using the ‘XLS’ button below the list of work orders on the request. Clicking this button opens a new window where you can select the columns you wish the export to contain. Export the record by clicking the ‘Export’ button.

Detailed information on creating work orders, the meaning of individual fields and other work order options is provided in the ‘Work Orders’ section of the documentation.

Adding fulfilments

One of the actions that can be performed on an existing request is to make the progress report for fulfilments available. The request handler uses fulfilments to record the work carried out whilst resolving the request. We divide fulfilments into billing fulfilments and internal fulfilments, the latter of which are not visible to the client. The fulfilment overview is available on the ‘Tasks’ tab in the request detail. This tab becomes available once a request has been created, and its visibility also depends on the authorization settings for the logged-in user.

You can create a billing fulfilment by clicking the + Add fulfilment button. Once you have clicked it, a form will appear for you to enter the required details.

Figure: Form for creating a fulfilment against a request

To create an internal transaction, click the ‘+ Add internal transaction’ button. Once clicked, a form similar to that for a billing fulfilment will appear.

You can create a transaction, regardless of its type, by clicking the ‘Create’ button. Once created, the quantity of fulfilments recorded for the request – which is displayed next to the ‘Fulfilments’ tab name – is automatically updated. Recorded fulfilments are displayed in a summary list; below the list is a ‘Summary’ section showing the total duration of the fulfilments.

Detailed information on creating tasks, the meaning of individual fields and other options for working with tasks can be found in the ‘Fulfilments’ section of the documentation.

Adding links to other requests

On the ‘Related Requests’ tab, you can link a request to existing requests or create a new one that is related to that request. A request can be created at the same level, or as a parent or child request.

To create a new request on this tab, click the ‘+ Add’ button. This will open the same form as when entering a new request.

Image: Form for creating a new related request

At the top of the form is the ‘Link’ selection list with the following options:

  • Links to
  • Copies
  • Is a copy of

To create a request, click the Create button.

+Add from catalogue button allows you to link a new request from the Catalogue of requests. Clicking it opens a window where you can select a company. Once selected, the tiles available to that company will be viewed. A form will then open, similar to the one used for submitting a request, with the individual fields pre-filled according to the template settings.

Figure: Selecting a request template to create a related request

You can use the Select Request button to link to an existing request in the system. Clicking this button opens a list of all requests that have been created. In the row containing the request, there is a tick box labelled , which you can use to select the required item; you can add the selected items by clicking the Confirm selection button.

Figure: Window for selecting related requests from existing requests

As with creating a new request, there is a field at the top of the window for selecting the relationship type – that is, whether the selected requests are copies of, or follow on from, a related request.

Parent and child requests

Within this section, it is possible to define parent and child requests, thereby creating a hierarchy of requests. The hierarchy supports multiple levels of nesting, e.g. Request A → Request B → Request C. The method for nesting requirements, whether by creating a new one or linking an existing one, is the same as for linking related requests – a detailed description is provided in the section above.

A link selects the current position of a request within the hierarchy;

  • It is a parent
  • It is a child

A request completion check is carried out for such requests – if a request contains child requests, it can only be completed once all child requests have been completed. When attempting to close a parent request that has open child requests, the system displays a notice indicating which child requests are still open.

Figure: Parent and child requests in the request detail

All changes to the requirements hierarchy are recorded in the request history – on a separate ‘History’ tab.

Figure: Requirement history – record of a child request being assigned

+Add from catalogue button allows you to create a child request from a request template. If a child request is being created from the same requirement template as the parent request, the user has the option to take the attribute values from the parent request when creating the child request. The user can choose to take all or selected attributes from the parent request. The pre-fill attribute values can be edited subsequently. Once a child request has been created, the attribute values are independent of those of the parent request (if the values in the parent request are changed, this change is not automatically applied to the child request).

Figure: Selecting custom fields from a parent request when creating a child request from the same template

Notification Settings

In the top right-hand corner of the request detail page, there are icons for setting notifications for that request. You can block notifications, enable them, set customer and SMS notifications, or add further recipients for notifications.

Image: Buttons for configuring notification settings for a request
  • All notifications enabled – notifications regarding changes to a request will be sent to all recipients – affected users, user groups and customer contacts who are set to receive notifications for requests. If notifications for requests are blocked in Global Settings → Notifications, only customer contacts will be notified; CDESK users will not be notified. You can switch between the following statuses by clicking repeatedly:
    •  All notifications blocked temporarily – the next saved change will not trigger any notification
    •  All notifications permanently blocked – notifications about changes to requests will not be sent until they are re-enabled
  • Customer notifications enabled – notifications regarding changes to a request will be sent to all the customer’s contacts who have opted in to receive notifications about requests. You can toggle between the following statuses by clicking repeatedly:
    • Customer notifications temporarily disabled – the next saved change will not send a notification to the customer’s contacts
    •  Permanently disabled customer notification – customer contacts will not receive notifications about changes to the request until they are re-enabled
  • SMS notifications enabled – click repeatedly to toggle between the following statuses:
    • SMS notifications temporarily disabled – the next saved change will not trigger an SMS notification
    •  SMS notifications permanently disabled – SMS notifications will not be sent until they are re-enabled
  • Edit notification recipients – clicking this will view a window listing the recipients of notifications for requests, discussions and comments for assignees. For automatically added recipients, the reason is also displayed. Recipients can also be added manually – either by entering their username, email address or telephone number in international format (+421 for Slovakia). Notification recipients can also be removed by clicking the X button in the row containing the relevant recipient. Recipients listed as the assignee, previous assignee, originator or responsible person cannot be removed. Contacts that have already been deleted can be added again by clicking the + button in the row containing the recipient’s name in the Deleted section.

View history

This section records all changes made to and saved in the request, for example:

  • Changes – priority, type, service area, status, assignee, date…
  • Notification information – recipients of notifications for discussion posts, blocking or enabling the sending of notifications
Figure: Example of a request history

Closing the Request

Once all actions have been done, the assignee sets the request status to ‘Completed’. If the ‘Accept completion’ option is enabled, options to accept or decline completion become available once the request has been closed. If notifications are enabled, the customer is also informed of the option to accept the completion via an email notification.

Figure: Buttons for accepting / non-acceptance of a request

If the ‘Carried out’ status is enabled in Global Settings → Requests → Request statuses, you can also apply this one. However, the ‘Carried out’ status is primarily intended for supervisors who are responsible for checking the work carried out on a request. Once a request has been switched to this status, the buttons for accepting or non-accepting the request will no longer appear.