Support and Workflow

Integria IMS allows you to control the workflow of your tickets. To this end, it has two sections: Workflow Rules and Status mapping.

In this section, you may define custom rules for automated ticket management. Due to the power of this feature, only admin users will be able to create/edit these rules.

The tickets that will be checked will be the open ones. To modify this performance, the ticket setup configuration will have to be modified.

In the Workflows section.

When a ticket from the Support group has not been answered for 48 hours, an email will be sent to the user in charge informing of this situation.

To register this Workflow rule, select the Create option:

and add a descriptive name:

Workflow rules have two execution modes:

• Cron: The Workflow rule verification will be done in each cron execution (overall it is usually every 5 minutes).
• Real time: Workflow rule verification will be done right when any ticket is created or edited.

From the list of workflow rules you may create new ones, edit existing ones, delete and enable/disable .

The next step will be to define the conditions that we want to be met. In our example, the ticket group is Support and has been without activity for more than 48 hours.

In this form we see all the options by which we can filter tickets for their management. With the Condition field you may choose whether you want all the conditions you select select to be met, some of them, or none. Once the condition is created, the list of conditions that make up the Workflow rule will be displayed.

The conditions that make up a Workflow rule can be one or more. To relate them to each other, the logical operators of the Operation field will be used:

• AND. Example: condition 1 and condition 2 must be met.
• OR. Example: condition 1 or condition 2 must be met.
• NOT. Example: condition 1 is not met.
• AND NOT. Example: condition 1 is met but not condition 2.
• OR NOT. Example: condition 1 is met or condition 2 is not met.
• XOR. Example: if any of the conditions is met.

The next step is to create the actions that you want to be carried out if the chosen conditions are met.

The actions that can be chosen are:

• Change the ticket priority.
• Change the ticket owner.
• Change the ticket group.
• Change the ticket status.
• Send an e-mail.
• Add a comment to the ticket.
• Change update date.
• Change resolution.
• Execute a command. This option is very powerful as it allows you to run a command on the server or a custom script.

Example:

• Block ticket . So that they cannot be modified.
• Unblock ticket.
• Change ticket type.

To configure the actions, you may use macros. These will be replaced by the value corresponding to the ticket.

• _incident_id_ : Ticket ID.
• _incident_title_ : Ticket title.
• _creation_timestamp_: Ticket creation date and time.
• _id_group_: Group ID assigned to the ticket.
• _name_group_: Name of the Group assigned to the ticket.
• _update_timestamp_: Last time the ticket was updated.
• _author_ : Ticket creator.
• _owner_: Ticket owner.
• _id_priority_: Ticket priority ID.
• _name_priority_: Ticket priority name.
• _access_url_: Direct URL to the ticket.
• _sitename_: Name of the site, as defined in the setup.
• _fullname_: Full name of the user who receives the mail.
• _username_: Identifying name of the user who receives the mail (login name).
• _id_status_: Incident status.
• _name_status_: Incident status name.
• _id_resolution_: Incident resolution ID.
• _name_resolution_: Incident resolution name.
• _incident_epilog_: Ticket epilogue.
• _incident_closed_by_: User who closed the ticket.
• _incident_own_email_: Email of the owner user.
• _incident_group_email_: Email of the assigned group.
• _incident_auth_email_: Email of the user who created the ticket.
• _name_group_: Name of the group assigned to the incident.
• _type_tickets_: Ticket type.
• Custom fields: They allow you to use the custom fields of the ticket types. The name of the custom fields you added can be included as a macro which will show the value of said field, the format would be: _custom field name_.

We are going to define a rule that is executed if: there is a highest priority ticket associated with the generic user “support” or it belongs to the Support group and has not been updated for at least 1 hour.

Now we will detail the conditions it must meet. The first condition is that it belongs to the user Support and is of the highest priority

And finally, that it stays at least 1 hour without being updated

The list of conditions would be like this

It belongs to the Support user OR it belongs to the Support group AND it has not been updated for more than an hour. Now it would be necessary to create the action.

One of the most important fields is ticket status. Through this field you may accurately track the ticket, whether it has just been created, if it has already been assigned to an operator, if it is waiting for external agents, pending closure, if it has been reopened or if it has already been closed. By default, you may move from one status to another without restrictions. But it is possible that you may want to specify status flow during the life cycle of the ticket.

Example: A team of operators is responsible for managing customer incidences. To ensure that the order of resolution is respected and guarantee customer service quality, by means of status mapping we will indicate that a ticket with a New status can only go to the Assigned or Pending status of a third party; From any of these three states, it can only go to Pending to be closed, and it will be from this that it can finally be Closed . In addition, from Closed the only possibility will be to go back to Reopen.

The configuration for this case would be: