Activities
Introduction to activities
An activity represents an action in a workflow. An activity is located within a scope and is of one of the following types:
- manual
- automatic
- scope
Using manual and automatic activities, you can model a rather strict business process where the engineer has to follow one of the provided paths for the ticket. Using scope activities you can model more flexible processes and prepare the CM system for case management where an engineer can react in a rather dynamic way, depending on the required circumstances.
Manual activities
A manual activity has to be performed by a manual action of the engineer using the Web Client GUI. The activity is displayed as Workflow activity in the Web Client, provided at least one of the roles of the engineer has the Execute permission (please refer to the ConSol CM Administrator Manual, section Role Administration, for a detailed explanation). In the Process Designer, the activity is marked by the red hand/manual icon.
Figure 29: ConSol CM Process Designer - Manual activity in workflow
Figure 30: ConSol CM Web Client - Manual activity
Automatic activities
An automatic activity is performed automatically by the system and is not displayed in the Web Client. In the Process Designer, an automatic activity is not marked by any special icon.
Figure 31: ConSol CM Process Designer - Automatic activities
Scope activities
A scope activity is located within a scope and does not have any incoming connections from other activities. In the Web Client, a scope activity is available as long as the ticket is placed within the scope. This holds true for all subordinate scopes. A scope activity might have subsequent activities (then is causes a process exception) but it can also be an activity without any connections (then it causes an interrupt). See section Interrupts and exceptions to learn more about interrupts and exceptions.
Please note that a ticket does not necessarily leave a scope when the "last" activity within the scope has been performed. See section Activities about this topic.
Figure 32: ConSol CM Process Designer - a scope activity (available in the scopes "Work in Progress" and "Ticket on hold")
Properties of an activity
Activities have the following properties:
-
name
Mandatory. This is the technical name of the activity. When an activity is newly created, you can edit the label and the activity name will be generated automatically from the label (special characters are omitted). Afterwards, the activity name is never changed automatically but can be edited manually. Allowed characters for names are:
- letters (small or capital), but no special characters
- underscores
- numbers
-
label
The localized name of the activity. All languages which have been configured for the system are available and can be filled. In the Web Client, the label is displayed according to the browser locale. If it is not available, the label of the default locale is shown.
-
description
Optional. A localized description which is displayed as a mouse-over in the Web Client. This might help the engineer to understand what will happen when the respective workflow activity is executed.
Figure 33: ConSol CM Web Client - Localized description of an activity as mouse-over
-
sort index
Defines the order of the activities in the list of workflow activities in the Web Client. The activities with a lower number are displayed first in the list.
-
overlay
Optional. Click into the orange space to define a standard ConSol CM overlay or one that has already been uploaded. Click the three dots button on the right to open the file explorer of the operation system to upload a new icon. When the ticket passes through an activity the overlay is added to the ticket icon in the Web Client. Up to three overlays can be attached to a ticket icon. This mechanism can be used for several purposes, some examples are:
- An escalation:
The ticket has been created without any engineer taking care of it. - An email:
The ticket has received an email. - A note for the engineer:
E.g. another engineer has added a comment to my ticket.
Figure 34: ConSol CM Process Designer - Properties editor: Standard overlays and one customer-defined overlay
Figure 35: ConSol CM Web Client - Ticket icons with overlays
- An escalation:
-
overlay range
Only displayed when an overlay has been set.
- Activity
The overlay is attached only as long as the ticket stands behind the activity or - if present - behind the last automatic activity which can be passed without manual interaction. As soon as the next manual activity is executed, the overlay is deleted from the ticket icon. - Scope
The overlay is deleted when the ticket leaves the scope. - Process
Once the overlay has been attached to the ticket icon, it stays there for the rest of the process. - Next overlay
The overlay is attached to the ticket icon as long as no new overlay appears. In that case, only the new one is attached, the old one is deleted.
In case you have to cover a use case where it is not sufficient to set or remove an overlay using the overlay range, you can use a workflow script. Please see section Working with overlays for details.
- Activity
-
Optional. A script can be entered using the script editor (see section Activities). The script has to return true or false. It is executed when the previous activity has been performed, i.e. when it becomes possible to display the activity with the precondition. In case true is returned, the activity is displayed, in case false is returned, the activity is not displayed. An activity which has a precondition is marked by the icon exclamation mark.
- Return value is true.
The activity is displayed. If it is a manual activity it can be performed by the engineer in the Web Client. - Return value is false.
The activity is not displayed in the Web Client.
Important note about customer fields
When you work with customer fields, i.e. with data fields that contain customer data, please keep in mind that it might be required to consider the data models of different customer groups in case a workflow is used for queues which have been assigned to more than one customer group! - Return value is true.
-
script
Optional. A script can be entered using the script editor (see section Activities) which is executed when the ticket enters the activity.
-
- automatic
The activity is performed automatically by the system. The action is transparent for the engineer. - manual
The activity is marked with the red hand/manual icon in the Process Designer GUI. The activity is available as workflow activity in the Web Client and is performed when the engineer has clicked on this activity. It is only available in a certain, strictly defined position of the ticket within the process. - scope
The activity is marked with the blue hand/manual icon in the Process Designer GUI. The activity is available like a workflow activity in the Web Client and is performed when the engineer has clicked on this activity. The scope activity is available as long as the ticket is located within the scope where the activity is placed or in one of the subordinate scopes.
For a detailed explanation of the ConSol CM process logic, please see section Process logic.
- automatic
-
history visibility
Mandatory. This property defines on which display levels the execution of the activity is shown in the ticket history in the Web Client. The possible values are:
- 2nd level and 3rd level
- only 3rd level
- on every level
- default (default value)
The activity is shown on the display level which is configured in the Admin Tool, navigation group Tickets, navigation item History. Depending on the type of activity, one of the following settings is used:
- Manual activity or activity with overlay executed
- Activity executed after escalation
- Automatic activity executed
- hidden on all levels
The execution of the activity is never displayed in the ticket history of the Web Client.
Figure 36: ConSol CM Web Client - Display levels in the ticket history
-
disable auto update
Defines the behavior of the ticket when an event has been fired or executed. Usually, after an event, a ticket update operation is performed automatically. In case a chain of events is used you should avoid triggering a ticket update operation after every single event. To avoid this, set disable auto update to true in all events except for the last one. Then, the ticket is only updated once, after the last event.
-
expose to customers
Boolean. Available for manual activities only. If checked, the activity is displayed as a workflow activity in the ConSol CM portal, CM/Track. The activity is only displayed in CM/Track if no precondition script is set or if the precondition script returns true. If an ACF (Activity Control Form) is attached to the activity, it is opened when the customer clicks the activity. An example of an ACF in CM/Track is shown in section ACFs in CM/Track.
Figure 37: ConSol CM Process Designer - Two activities which should be displayed for CM/Track customers ("exposed to customers")
Figure 38: CM/Track (i.e. customer perspective) - Two activities which are displayed in CM/Track for customers ("exposed to customers")
Process logic of activities
This is the process logic of activities:
- When a ticket has passed through an activity it always waits behind this activity (and not before the next one!).
- When a ticket has passed through an activity, it checks if one of the potential subsequent activities is an automatic activity. If yes, the ticket passes through this automatic activity as well. This is why there can only be one automatic activity in a process step.
- The ticket passes automatically through (automatic) activities as long as there are new automatic activities. It comes to a halt as soon as there is/are one or more manual activities where engineer interaction is required.
- If one or more of the following manual activities have a precondition script, this script is executed in order to decide if the activity has to be displayed in the Web Client GUI or not.
- If the engineer selects the activity in the Web Client GUI, the script of the activity is executed.
- If there is a postActivityScript, this script is executed immediately after the execution of the activity script.
- The ticket waits behind the manual activity. If the following activity is located in a new scope, the ticket will not enter the new scope. It always waits behind the old activity and not before the new one!
In case the activity has an ACF, the Business logic of ACFs also has to be considered.
Remark on scope activities
A scope activity does not have any incoming connections, but it can have
- a condition script
- an activity script
- outgoing connections
When a scope activity has been executed, the subsequent position of the ticket depends on the workflow topology:
- If there are no subsequent activities which are directly linked to the scope activity, the ticket executes the scope activity and returns to its previous position within the workflow. This is an interrupt.
- If there are subsequent activities which are linked to the scope activity, the ticket will execute these activities. It will wait after the scope activity, if the subsequent activity is a manual activity. It will pass on through a subsequent automatic activity. This behavior represents an exception. It is even possible that the ticket leaves the workflow (the queue), if a jump-out node is positioned behind a scope activity, or that the ticket is closed, if an end node is positioned behind a scope activity.
A ticket always waits behind the last activity which has been executed and not before the new one!
This is relevant, for example, when a view is defined: it is important to know that the ticket might not have entered the next scope, because it is still waiting behind the previous activity in the current scope.
If the ticket temporarily leaves its scope due to the execution of a scope activity, triggers are restored when the ticket reenters the scope afterwards.
Examples of activities
Example 1: Precondition for displaying an activity
In case the ticket has been opened by a VIP contact, i.e., a contact where the boolean field vip is true, the team lead should be informed. If it is no VIP, the activity Inform team lead should not be displayed. The customer field vip which is part of the customer data model is checked for this purpose.
Figure 39: ConSol CM Process Designer - Workflow activities (one with precondition script)
import com.consol.cmas.core.server.service.*
import com.consol.cmas.common.model.customfield.meta.UnitDefinitionType
def ticket = workflowApi.ticket
// fetch main contatc of the ticket
def maincontact = ticket.getMainContact()
def unit_type = maincontact.definition.type
log.info 'vipCheck: Unittype is ' + unit_type
log.info 'vipCheck: Unittype class is ' + unit_type.getClass()
if(unit_type == UnitDefinitionType.COMPANY) {
log.info 'No vipCheck for comapnies possible! Returning false ... '
return false
} else if (unit_type == UnitDefinitionType.CONTACT){
// fetch e-mail address of the man contact. The data object group field has to be addressed using data object group name:data object group field name
def vip_field
def custgroup = maincontact.customerGroup.name
println 'vipCheck: Customergroup is now ' + custgroup
switch(custgroup) {
case "Reseller": vip_field = "vip_person";
break;
case "DirectCustomers": vip_field = "vip_dircust"
break;
case "MyCustomerGroup": vip_field = "vip"
break;
case "OurPartnerCompanies": vip_field = "vip_partners"
break;
case "RetailCustomers": vip_field = "retail_vip"
break;
}
def vip_value = maincontact.get(vip_field)
log.info 'VIP is now ' + vip_value
if (vip_value){
return true
} else {
return false
}
}
Code example 2: Precondition script: activity should only be displayed for VIP customers
Figure 40: ConSol CM Admin Tool - Customer field "vip"
Figure 41: ConSol CM Web Client - Precondition: Return value TRUE
Figure 42: ConSol CM Web Client - Precondition: Return value FALSE
Example 2: Sending an email to the main contact after opening a ticket
When a ticket has been opened, an email should be sent automatically to the main contact of the ticket.
Figure 43: ConSol CM Process Designer - Automatic activity where receipt note is sent
Script in workflow activity Send notice of receipt:
log.info'Calling SendReceiptNotice script ...'
scriptExecutionService.execute("SendReceiptNotice.groovy")
Script SendReceiptNotice.groovy in Admin Tool:
import com.consol.cmas.common.model.mail.Mail
import com.consol.cmas.common.util.MailHeadersUtil;
import com.consol.cmas.core.server.service.*;
import static com.consol.cmas.common.util.TemplateUtil.TICKET_SUBJECT_TEMPLATE_NAME;
import com.consol.cmas.common.model.customfield.meta.UnitDefinitionType
// create new mail object
def mail = new Mail()
def ticket = workflowApi.getTicket()
// fetch main contatc of the ticket
def maincontact = ticket.getMainContact()
def unit_type = maincontact.definition.type
log.info 'Mailscript: Unittype is ' + unit_type
log.info 'Mailscript: Unittype class is ' + unit_type.getClass()
if(unit_type == UnitDefinitionType.COMPANY) {
println 'No email address for company; no receipt notice sent.'
return
} else if (unit_type == UnitDefinitionType.CONTACT){
// fetch e-mail address of the man contact. The data object group field has to be addressed using data object group name:data object group field name
def toaddress_field
def custgroup = maincontact.customerGroup.name
switch(custgroup) {
case "Reseller": toaddress_field = "email";
break;
case "DirectCustomers": toaddress_field = "dir_cust_email"
break;
case "MyCustomerGroup": toaddress_field = "email"
break;
case "OurPartnerCompanies": toaddress_field = "email"
break;
case "RetailCustomers": toaddress_field = "retail_customer_email"
break;
}
def toaddress = maincontact.get(toaddress_field)
if (!toaddress){
log.info 'No email address found for contact, no receipt notice sent.'
} else {
// put the e-mail TO address into the Mail object
mail.setTo(toaddress)
// fetch the REPLY TO address, theis is stored in a system property
def replyaddress = configurationService.getValue("cmweb-server-adapter","mail.reply.to")
// put the e-mail REPLY TO address into the Mail object
mail.setReplyTo(replyaddress)
// build e-mail text using a template which is stored in the Template Designer
def text = workflowApi.renderTemplate("Acknowledgement_of_receipt")
// put the e-mail text into the Mail object
mail.setText(text)
// create the subject of the e-mail, the ticket number with the correct Regular Expression
// has to be set for correct recognition of incoming e-mails for the ticket
// ****** alternative solutions for PD manual! *****
// solution 1:
// def ticketname = ticket.getName()
// def subject = "Your case has been registered as Ticket (" + ticketname + ")"
// solution 2: (needs import of TemplateUtil.TICKET_SUBJECT_TEMPLATE_NAME
def subject = templateService.merge(TICKET_SUBJECT_TEMPLATE_NAME, [ticketName:ticket.name])
// put the subject into the Mail object
mail.setSubject(subject)
// Mail should use the e-mail script which is configured for the queue
mail.useDefaultScript()
// send out the e-mail and register status
def attList = new ArrayList<AttachmentEntry>()
def collection = new HashSet<MailEntry>()
def mailStatus = true;
try {
mail.send();
} catch (Exception e){
mailStatus = false;
}
} // end if (!toaddress){
} // end of else if (unit_type.equals('COMPANY')){
Code example 3: Scripts for automatic activity where receipt note is sent, variant 1
// lines of code alost identical to variant 1 except for the sending of the mail:
new Mail().setSubject( subj ).setTo( contact_e ).setReplyTo( replyto ).setText( text ).setTicketAttachments( null ).send()
Code example 4: Script for automatic activity where receipt note is sent, variant 2
Example 3: Assign the ticket to the current engineer
The ticket should be assigned to the engineer who executes the activity New IT ticket.
Figure 44: ConSol CM Process Designer - Workflow activity where engineer should be assigned
Figure 45: ConSol CM Web Client - Ticket passed through activity where engineer was assigned
// Get the engineer who is executing the activity:
// Java Style is possible: def curr_eng = workflowApi.getCurrentEngineer()
// we use Groovy style here:
def curr_eng = workflowApi.currentEngineer
// alternative would be:
// def curr_eng = engineerService.current
// Assign the ticket to the current engineer
// Java style is possible:
ticket.setEngineer(curr_eng)
// groovy alternative would be:
// ticket.engineer = curr_eng
Code example 5: Script for assigning ticket to current engineer
Make sure that you always use the correct engineer object!
The current engineer is the engineer who is logged in, who is executing the current activity. You can get the object by using one of the following methods.
Using workflowApi:
// Java notation
def curr_eng = workflowApi.getCurrentEngineer()
// Groovy notation
def curr_eng = workflowApi.currentEngineer
Using engineerService :
// Java notation:
def curr_eng = engineerService.getCurrent()
//Groovy notation
def curr_eng = engineerService.current
The ticket engineer is the person who is (at this point of time) the ticket owner and responsible for the ticket. You can get the object by using the following method:
//Java notation
def tic_eng = ticket.getEngineer()
//Groovy notation
def tic_eng = ticket.engineer
Example 4: Using a scope activity
The scope activity Forward problem to supervizor should be present for the entire life cycle of the ticket. For really problematic tickets, the engineer can use a "shortcut": the ticket does not have to be moved through the entire process but can be directly sent to a special management queue where a supervisor takes care of it.
Figure 46: A scope activity which will be available throughout the entire life cycle of the ticket, because the activity is placed in the global scope