This chapter discusses the following:
One of the core functionalities of ConSol CM is its interaction with an e-mail infrastructure. This makes it possible for the engineer to send manual e-mails and for the system to send automatic e-mails to customers and to engineers, as required in the respective process step. Obviously, ConSol CM has also to receive e-mails. This is done by retrieving e-mails from one or more mailboxes with ConSol CM-owned addresses. For a detailed explanation of all interactions between the mail server and ConSol CM, please refer to the ConSol CM Administrator Manual and the ConSol CM Operations Manual. Here, only the workflow interactions are explained.
Figure 69: ConSol CM Process Designer - Mail trigger
When an e-mail is received which belongs to an existing and active (open) ticket, it might be required to register this action and to perform specific actions subsequently. This can be achieved using one or more mail triggers within a workflow.
Please keep in mind that (in the default configuration, i.e. without modification of the Admin Tool script AppendToTicket.groovy) the only automatic action, which is performed by ConSol CM after having received an e-mail in a specific mailbox, is to attach this e-mail to the ticket with the matching ticket tag in the subject, e.g. Ticket (<TicketNumber>). See also ConSol CM Administrator Manual section Scripts of Type E-Mail.
All other actions, which should be executed when an e-mail has been received, have to be programmed manually in the workflow (and/or in Admin Tool scripts)!
Examples for the use of mail triggers are:
When an e-mail has been received ...
When a mail trigger is attached to an activity, this activity is only executed when an e-mail is received.
Figure 70: ConSol CM Process Designer - Mail trigger at activity
Grab the mail trigger icon in the palette and drop it into the desired scope. It is automatically attached to the top of the scope. You can modify the position afterwards (move it to the left or right in order to improve the layout). Only one mail trigger can be used per scope.
A mail trigger which has been attached to a scope cannot be moved to another scope. In case you would like to attach a mail trigger to another scope, remove the one you have defined and create a new one for the correct scope.
You can draw connections from the trigger to put activities or decision nodes behind it. The first step which is executed after a mail trigger always has to be an automatic activity!
In the very rare case that you have to attach a mail trigger to an activity (we do not recommend this!), grab the mail trigger icon in the palette and drop it into the desired activity. It will be attached to the corner of the activity.
A mail trigger which has been attached to an activity cannot be moved to another scope or activity. In case you would like to attach a mail trigger to another scope/activity, remove the one you have defined and create a new one for the correct scope/activity.
A mail trigger does not have any properties.
When an e-mail has been received for a ticket which is currently in the scope, the ticket icon in the Web Client GUI should be marked with the overlay mail.
The mail trigger is attached to the scope and the overlay is attached to the automatic activity which is connected to the trigger. The overlay range is activity.
That way, the ticket is marked with the overlay when the e-mail has come in. As soon as an engineer has moved the ticket to another activity, the overlay disappears.
Please note that the ticket does not leave its context. All that happens is the attachment of the overlay to the ticket icon. Then the ticket returns to its original position in the workflow. We call this an interrupt. Please read the section Process Logic for a detailed explanation.
Figure 71: ConSol CM Process Designer - Use case 1: Scope with mail trigger
Figure 72: ConSol CM Web Client - Use case 1: Ticket with overlay icon
When an e-mail has been received for a ticket which is currently in the scope, the ticket icon in the Web Client GUI should be marked with the overlay mail. Additionally, the ticket should be transferred to a position where it waits until the engineer has confirmed that he/she has read the e-mail.
The mail trigger is attached to the scope and the overlay is attached to the adjacent automatic activity. The overlay range is activity. That way, the ticket is marked with the overlay when the e-mail has come in.
Within the script which follows the mail trigger, a boolean field mail_to_read is set to true. In the workflow, an activity Confirmed: e-mail read! is offered wherever required. It is only displayed in case the value of the boolean field mail_to_read is true. This is a stronger mechanism to remind the engineer of an incoming e-mail than to use only the overlay. The engineer has to confirm the e-mail by executing the workflow activity Confirmed: e-mail read! explicitly. Within this workflow activity the value of the boolean field mail_to_read is set back to false. Now the ticket is ready to receive another e-mail and to notify the engineer.
Please note that also in this case the ticket does not leave its context as a consequence of the action which is executed after the e-mail has come in. All that happens is the attachment of the overlay to the ticket icon and the modification of a boolean variable. The ticket returns to its original position in the workflow. So this is also an interrupt. Please read the section Process Logic for a detailed explanation.
Figure 73: ConSol CM Process Designer - Use case 2: Scope with mail trigger
Figure 74: ConSol CM Process Designer - Use case 2: Properties of activity "E-mail received"
Figure 75: ConSol CM Admin Tool - Use case 2: New boolean field to register e-mail
Figure 76: ConSol CM Process Designer - Use case 2: Script for activity "E-mail received"
Figure 77: ConSol CM Process Designer - Use case 2: Activity for e-mail confirmation
Figure 78: ConSol CM Process Designer - Use case 2: Properties of activity "Confirmed: e-mail read!"
Figure 79: ConSol CM Process Designer - Use case 2: Precondition script for activity "Confirmed: e-mail read!"
Figure 80: ConSol CM Process Designer - Use case 2: Script for activity "Confirmed: e-mail read!"
Figure 81: ConSol CM Web Client - Use case 2: Workflow activity "Confirmed: e-mail read!"
When an e-mail is received, the mail trigger of the innermost possible scope fires.
Example 1:
The ticket is at position (1) in the Ticket on hold scope. When an e-mail comes in, the mail trigger for this scope fires (2) and, as a consequence, the ticket is moved to another scope (3).
Figure 82: ConSol CM Process Designer - Example 1: Mail trigger of sub-scope active
Example 2:
The ticket is at position (1) in the Work in progress scope. When an e-mail comes in, the mail trigger of the main scope (2) fires (because the Work in progress scope does not have a mail trigger). So the ticket position is not changed (3).
Figure 83: ConSol CM Process Designer - Example 2: Mail trigger of main scope active