Support and Workflow

Back to Pandora FMS documentation index

Integria IMS allows you to control the workflow of your tickets. To do this, it has two sections: Workflow rules (Workflow rules) and State mapping (Status mapping).

In this section you can define custom rules for automated ticket management. Due to the power of this functionality, 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 behavior, you will have to change the ticket setup configuration.

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 responsible user informing them of this situation.

To register this Workflow rule we select the Create option:

and we will give a descriptive name:

Workflow rules have two execution modes:

• Cron: The verification of the Workflow rules will be done at each execution of the cron (usually every 5 minutes).
• Real time: The verification of the Workflow rules will be done at the same moment that any ticket is created or edited.

From the list of workflow rules we can 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 it 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 can choose if you want all the conditions you select to be met, some 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 have to be met.
• OR. Example: either condition 1 or condition 2 has to be met.
• NOT. Example: Condition 1 is not met.
• AND NOT. Example: condition 1 is met and not condition 2.
• OR NOT. Example: condition 1 is met or condition 2 is not met.
• XOR. Example: if any of the conditions are met.

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

The actions that can be chosen are:

• Change ticket priority.
• Change the owner of the ticket.
• Change the ticket group.
• Change 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.
• Unlock ticket.
• Change the type of ticket.

To configure the actions, we can make use of macros. These will be replaced by the value corresponding to the ticket.

• _incident_id_ : ID of the ticket.
• _incident_title_ : Title of the ticket.
• _creation_timestamp_: Date and time of ticket creation.
• _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_: Owner of the ticket.
• _id_priority_: Ticket priority ID.
• _name_priority_: Name of the ticket priority.
• _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_: Identifier name of the user who receives the mail (login name).
• _id_status_: ID of the status of the incident.
• _name_status_: Name of the status of the incident.
• _id_resolution_: Incident resolution ID.
• _name_resolution_: Incident resolution name.
• _incident_epilog_: Ticket epilog.
• _incident_closed_by_: User who closes 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 Field Templates: Allows you to use the custom fields of the ticket types. The name of the custom fields that you added can also 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 in case of: there being a highest priority ticket associated with the generic user “support” or belonging to the Support group and that has not been updated for at least 1 hour.

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

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

The list of conditions would look like this

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

The status of a ticket is one of the most important fields. Through this field we can accurately track the ticket, whether it has just been created, has already been assigned to an operator, is waiting for external agents, is pending closure, has been reopened or has already been closed. By default, you can go from one state to another without restrictions. But we may want to concretize the flow of states during the lifecycle of the ticket.

Example: we have a team of operators responsible for customer incident management. To make sure that the order of resolution is respected and guarantee a quality of service to the customer, by means of the status mapping we will indicate that a ticket with a status of New can only go to the statuses Assigned or Pending third person; from any of these three states it can only go to Pending to be closed, and it will be from this state that it can finally be Closed. Also, from Closed the only possibility will be to return to Reopened. The configuration for this case would be like this:

Back to Pandora FMS documentation index