Open topic with navigation

Queue Administration

Introduction

Queues are a central element of ConSol CM. Tickets are grouped in queues, e.g., for certain tasks or work groups. Each queue is assigned a single workflow which controls the processing steps of all tickets in this queue. For example, there might be one queue Helpdesk, one queue Marketing, and one queue Sales.

The following parameters and objects are assigned to a queue (the parameters and objects are defined on other Admin Tool tabs, and are assigned to a new or existing queue here):

• The workflow of the queue (mandatory), i.e., the process which should be used for all tickets in the queue (e.g., all tickets of a department). A queue can only have one workflow but a workflow can be used by multiple queues.
• The template for the e-mails which are sent to engineers when a ticket is assigned or removed (optional).
• Several scripts that define the behavior of tickets in this queue (optional).
• One or more customer group(s) which are associated with the queue. Tickets can only be added to the queue for customers of this/these group(s) (one customer group is mandatory, more are optional).
• The business calendar (i.e., the working hours) which should be applied for tickets in this queue (optional).
• The data fields (Custom Fields) which should be available in tickets in this queue. They are defined by assigning Custom Field Groups to the queue (some mandatory, some optional).
• The classes of text which should be available for tickets in this queue (optional).
• The project(s) which should be available for time booking in tickets of the queue (optional).

As a central element, the queue uses various objects and elements that are defined in other places, i.e., on another page of the Admin Tool, so usually all elements which are required for the definition of a queue are defined first. However, except for the workflow, all parameters can be modified after a queue definition has been saved for the first time (i.e. after the queue has been created), so you can configure the queue using an iterative approach if you like.

Furthermore, a queue is the basis for the assignment of access permissions, please see section Role Administration for details.

Queue Administration Using the Admin Tool

In the Admin Tool, queues are managed on the navigation item Queues in the navigation group Global Configuration.

Figure 229: ConSol CM Admin Tool - Queue administration

Filter the Queue List

Queues you want to edit or copy can be found most quickly if you enter filter information in the fields above the queue list.

You can filter for queues which

• contain a certain text string (blanks are interpreted, too) and/or
• are specific for customer groups.

Create a Queue

You create a new queue by clicking the Add button below the queue list. The following pop-up window appears:

Figure 230: ConSol CM Admin Tool - Queue administration: Create a queue

Here, you can define the queue details:

• Queue:
  Enter the technical queue name in this field. Click the Localize button to enter the localized queue name for all languages that are available in the system. The localized queue name (depending on the web browser locale) will be displayed in the Web Client in the ticket header. If no localized values are provided, the technical name will be displayed.
• Workflow:
  Choose the workflow for the queue from this list.

  When you have developed and deployed a new workflow, it will only be available in the Admin Tool after a reload of Admin Tool data!

  Once you have assigned a workflow to a queue it cannot be changed anymore!

• Prefix:
  You can enter a prefix for the ticket IDs of a queue, e.g., when the ticket ID should indicate to which queue or organizational structure it belongs.

  The prefix remains with the ticket name if the ticket is moved to another queue.

• Calendar:
  Choose the business calendar for the queue from the list. Business Calendars in CM define working hours, holidays and the valid time zone (see section Business Calendars). They are used, e.g., for time triggers in the workflow and have to be activated explicitly for each trigger, i.e., in order to work with time calculations based on a business calendar, it has to be configured in three places:
  • In the navigation group Global Configuration, navigation item Business Calendars the calendar is created and the active and vacation times are configured.
  • In the queue administration a calendar is assigned to the queue.
  • For each time trigger in the workflow the use of the queue-specific calendar can be activated or not. Refer to the ConSol CM Process Designer Manual for a detailed explanation of working with time triggers.
• Enable:
  If this checkbox is checked, the queue is immediately available in the system after saving, otherwise the queue is disabled. In enabled queues, you can create tickets. In disabled queues, this is not possible.
• FAQ:
  Ticking this checkbox marks the queue as a knowledge base for CM.Track users. They can search for tickets in this queue in CM.Track, the ConSol CM Web Portal. Please see also section CM.Track V1: FAQs in CM.Track or CM.Track V2: FAQs in CM.Track for more information about this topic.
• Ticket assignment templates:
  Here you can choose e-mail templates which are used for automatic e-mails which are sent to the (new) engineer when a ticket is assigned to an engineer (Assign), or to the (old) engineer when a ticket is taken away (Unassign). When you have defined the templates in the Scripts & Templates Administration of the Admin Tool (see section Admin Tool Templates) they will be available in the drop-down menu. If you do not want the ConSol CM system to send an automatic e-mail in case of the engineer operation, just leave the field empty. Please keep in mind that the system properties cmas-core-server, mail.notification.engineerChange (=true) and cmas-core-server, mail.notification.sender have to be set, see System Properties for details.
• Scripts:
  Scripts are used to automate recurring tasks and activities. They are managed and stored in the Scripts & Templates Administration (see section Admin Tool Scripts). You can assign:
  • E-mail script
    Choose a script from the list if outgoing e-mails for this queue should be modified by the script, e.g., to contain default values like the sender or address fields. The e-mail script indicated here is the last script that processes an outgoing e-mail, so all former settings will be overwritten if a variable has been set before. All scripts of type E-mail that are stored in the script section are available for selection, so please make sure to pick the correct one.

  When you work with the configuration of the REPLY-TO e-mail address, please note the following technical behavior of ConSol CM and adapt your system accordingly!

  The technical background:

  There are four potential REPLY-TO addresses which you deal with:

  1. The REPLY-TO address which is set with the system property mail.reply.to. If it is set, it will be displayed in the Ticket E-Mail Editor in the Web Client. If it is really the effective REPLY-TO address in an e-mail depends on the configuration in the queue-specific outgoing e-mail script. See next item. If the Page Customization attribute showReplyTo for the type mailTemplate is set to false, no REPLY-TO address will be displayed in the Ticket-E-Mail-Editor, but if the property mail.reply.to is set, this address will be used anyway - unless an outgoing mail script sets another address, see next item.
  2. The REPLY-TO address which is set in a queue-specific outgoing e-mail script. Since the outgoing e-mail script is the last instance which processes an outgoing e-mail, the REPLY-TO address set in this script will always be the effective REPLY-TO address which is used. In case the mail.reply.to property is set, this mail-reply.to-address will not really be used (but it will be displayed in the Ticket E-Mail Editor which might cause some confusion! What that means for your system configuration is explained in the next section).
  3. The e-mail address which is set in the system property mail.from. If this is set and neither mail.reply.to nor a queue-specific REPLY-TO address is set, most e-mail clients will set the FROM address as REPLY-TO address.
  4. The e-mail address of the current engineer (the engineer who is logged in to the Web Client). This personal e-mail address is used as REPLY-TO address for e-mails from the Web Client if neither the mail.reply.to property is set nor a queue-specific outgoing e-mail script is configured nor the mail.from property is set.

  In the Web Client, in the ticket history, the REPLY-TO address which was really used is always displayed for outgoing e-mails. So even in case there should be a difference between the address which was displayed in the Ticket E-Mail Editor (the mail.reply.to property) and the REPLY-TO address which was really used (the REPLY-TO in the queue-specific outgoing e-mail script), the effective address is displayed. This would be the one from the script in this case.

  What we recommend:

  A system REPLY-TO address should always be set! You can decide if you

  • work with the REPLY-TO address in the queue-specific outgoing e-mail script

  or

  • use the mail.reply.to system property.

  However, since the e-mail communication should take place via ConSol CM and not using personal e-mail addresses, one of the two system settings mentioned above should be used to prevent CM from using personal e-mail addresses as REPLY-TO. The latter would automatically lead to customer e-mails being sent to an engineer's personal e-mail account instead of CM.

  What that means for your system configuration:

  1. The simplest way to set a REPLY-TO address is by using the mail.reply.to system property. It will be displayed in the Ticket E-Mail Editor and will be the effective REPLY-TO address.
  2. If queue-specific REPLY-TO addresses are required, we recommend to write one outgoing mail script where queue names are mapped to specific REPLY-TO addresses. This can then be extended for BCC, CC or other addresses.
     You can combine the mail.reply.to property and queue-specific REPLY-TO addresses: for all queues without a specific outgoing mail script, the mail.reply.to address will be used, for all queues which have a queue-specific outgoing mail script that contains a REPLY-TO address, this will be used.

  What that means when you work with workflow scripts which send e-mails:

  (A detailed explanation is provided in the ConSol CM Process Designer Manual!)

  • Use the object and method configurationService.getValue("cmweb-server-adapter","mail.reply.to") to retrieve the value of the system property and set it as REPLY-TO address in the outgoing e-mail.
  • Use the Mail object when the queue-specific script should be used: e.g. mail.useDefaultScript() . This will overwrite the mail.reply.to property!

  If neither the system property nor the queue-specific outgoing e-mail script is used, i.e. when the REPLY-TO address is not set, usually the FROM address will be used as REPLY-TO by the e-mail client.

  • Default values script
    Here you can select a script to preset values of list boxes when creating a ticket for this queue in the Web Client. The script has to be present in the Scripts & Templates Administration of the Admin Tool and has to be of type Default values. Please refer to section Scripts of Type Default Values for details about this topic.
  • Clone script
    Here you can select a script which is executed when a ticket in this queue is cloned (duplicated) using the Web Client (Clone option in the ticket menu). The script has to be present in the Scripts & Templates Administration of the Admin Tool and has to be of type Clone. The clone script sets default values for a ticket which is created using the Clone operation. Please refer to section Scripts of Type Clone for details.
• Description:
  You can enter a free-form description in this field, e.g., to document the purpose of the queue. This information is shown in the Admin Tool only.
• Tab Custom Fields:
  In order to show data fields (Custom Fields) in tickets of the queue, you have to assign the respective custom field groups here. See section Custom Field Administration (Setting Up the Ticket Data Model) for details about the definition of Custom Fields.
• Tab Customer groups:
  Tickets in the queue can only be created for customers from the selected customer groups. Please make sure that the engineers who are supposed to work with tickets of the queue also have the respective access permissions to the customer (group) data.
• Tab Classes of text:
  Here you can assign the classes of text which should be available in tickets of this queue. Please see section Classes of Text for an explanation of the text class definition.
• Tab Projects:
  Here you can assign projects to the queue. Engineers who work on a ticket in the queue can book times on the projects that have been assigned to the queue. Projects are defined on the Projects page.

On each tab you can assign a selected entry by clicking the Assign button and remove it by clicking the Unassign button.

Click Save afterwards to create the queue. The details of the new queue are displayed on the right-hand side of the page.

Edit a Queue

If you want to edit a queue, select it in the list and click the Edit button or double-click the name of the queue. Modify the queue details and click Save to store your modifications.

You cannot change the workflow of a queue once the queue has been saved for the first time!

Delete a Queue

Select the queue you want to delete in the list and click the Delete button. If you confirm the following dialog with Yes, the queue will be deleted and is no longer available in the system.

If there are still tickets for a queue it cannot be deleted. You have to move the tickets to another queue before you can delete it.

Copy a Queue

The Copy button allows you to save time when creating a queue. The selected queue will be copied. The new queue has the same name as the copied queue. Double-click the name or click the Edit button to open the edit window where you can modify the name and details of the queue. Click Save to store your modifications.

You cannot change the workflow of a queue once the queue has been saved for the first time!

Enable or Disable a Queue

You can disable a queue to prevent that new tickets can be opened in this queue. This allows a queue to be made temporarily unavailable without having to delete it. To disable a queue, select the queue in the queue list and click the Deactivate button. The entry in the list is now shown in italics. Just click the Activate button at the bottom of the page to enable the queue again.

You can still read tickets in a disabled queue (provided you have read access rights for this queue), but you cannot process tickets, i.e., they cannot be moved to the next step in the process using workflow activities.