Soporte y Workflow

Volver al índice de documentación de Pandora FMS

Integria IMS permite controlar el flujo de trabajo de sus tickets. Para ello, cuenta con dos secciones: Reglas de Workflow (Workflow rules) y Mapeo de estados (Status mapping).

En esta sección se pueden definir reglas personalizadas para la gestión de tickets de forma automatizada. Debido a la potencia de esta funcionalidad, solo los usuarios administradores podrán crear/editar estas reglas.

Los tickets que se comprobarán serán los abiertos. Para modificar este comportamiento, habrá que cambiar la configuración del setup de tickets.

En el apartado Flujos de trabajo.

Cuando un ticket del grupo Soporte lleva 48 horas sin respuesta, se enviará un email al usuario responsable informando de esta situación.

Para dar de alta esta regla de Workflow seleccionamos la opción Crear:

y daremos un nombre descriptivo:

Las reglas de workflow tienen dos modos de ejecución:

• Cron: La comprobación de las reglas de Workflow se hará en cada ejecución del cron (normalmente suele ser cada 5 minutos).
• Tiempo real: La comprobación de las reglas de Workflow se hará en el mismo instante en que se crea o edita cualquier ticket.

Desde el listado de reglas de workflow podremos crear nuevas, editar las ya existentes, borrary habilitar/deshabilitar .

El siguiente paso será definir las condiciones que queremos que se cumplan. En nuestro ejemplo, que el grupo del ticket sea Soporte y lleve más de 48 horas sin actividad.

En este formulario vemos todas las opciones por las que podemos hacer el filtrado de tickets para su gestión. Con el campo Condición se puede elegir si queremos que se cumplan todas las condiciones que seleccionemos, se cumpla alguna o no se cumpla ninguna. Una vez creada la condición, se mostrará el listado de condiciones que componen la regla de Workflow.

Las condiciones que componen una regla de Workflow pueden ser una o varias. Para relacionarlas entre sí, se utilizarán los operadores lógicos del campo Operación:

• AND. Ejemplo: se tiene que cumplir la condición 1 y la condición 2.
• OR. Ejemplo: se tiene que cumplir la condición 1 o la condición 2.
• NOT. Ejemplo: no se cumple la condición 1.
• AND NOT. Ejemplo: se cumple la condición 1 y no la condición 2.
• OR NOT. Ejemplo: se cumple la condición 1 o no se cumple la condición 2.
• XOR. Ejemplo: si se cumple alguna de las condiciones.

El siguiente paso es crear las acciones que queremos que se lleven a cabo si se cumplen las condiciones elegidas.

Las acciones que se pueden elegir son:

• Cambiar la prioridad del ticket.
• Cambiar el propietario del ticket.
• Cambiar el grupo del ticket.
• Cambiar el estado del ticket.
• Enviar correo electrónico.
• Añadir un comentario al ticket.
• Cambiar fecha de actualización.
• Cambiar resolución.
• Ejecutar un comando. Esta opción es muy potente ya que permite ejecutar un comando en el servidor o bien un script personalizado.

Ejemplo:

• Bloquear ticket. Para que no se puedan modificar.
• Desbloquear ticket.
• Cambiar el tipo de ticket.

Para configurar las acciones, podemos hacer uso de las macros. Estas se sustituirán por el valor correspondiente al del ticket.

• _incident_id_ : ID del ticket.
• _incident_title_ : Título del ticket.
• _creation_timestamp_: Fecha y hora de la creación del ticket.
• _id_group_: ID del Grupo asignado al ticket.
• _name_group_: Nombre al Grupo asignado al ticket.
• _update_timestamp_: Última vez que se actualizó el ticket.
• _author_: Creador del ticket.
• _owner_: Propietario del ticket.
• _id_priority_: ID de la prioridad del ticket.
• _name_priority_: Nombre de la prioridad del ticket.
• _access_url_: URL directa al ticket.
• _sitename_: Nombre del sitio, tal y como se haya definido en el setup.
• _fullname_: Nombre completo del usuario que recibe el correo.
• _username_: Nombre identificador del usuario que recibe el correo (login name).
• _id_status_: ID del Estado del incidente.
• _name_status_: Nombre del Estado del incidente.
• _id_resolution_: ID de la resolución del incidente.
• _name_resolution_: Nombre de la resolución del incidente.
• _incident_epilog_: Epílogo del ticket.
• _incident_closed_by_: Usuario que cierra el ticket.
• _incident_own_email_: Email del usuario propietario.
• _incident_group_email_: Email del grupo asignado.
• _incident_auth_email_: Email del usuario creador del ticket.
• _name_group_: Nombre del grupo asignado al incidente.
• _type_tickets_: Tipo de ticket.
• Plantillas de campos personalizados: Permiten usar los campos personalizados de los tipos de tickets. El nombre de los campos personalizados que agregaste también puedes incluirlos como una macro la cual mostrará el valor de dicho campo, el formato sería: _nombre_del_campo_personalizado_.

Vamos a definir una regla que se ejecute en caso de: existir un ticket de máxima prioridad asociado al usuario genérico “soporte” o pertenezca al grupo Soporte y que lleve al menos 1 hora sin ser actualizado.

Ahora detallaremos las condiciones que debe cumplir. La primera condición es que pertenezca al usuario Soporte y sea de máxima prioridad

Y por último, que lleve al menos 1 hora sin ser actualizado

El listado de condiciones quedaría así

Pertenece al usuario Soporte O pertenece al grupo Soporte Y lleva más de una hora sin actualizarse. Ahora faltaría crear la acción.

El estado de un ticket es uno de los campos más importantes. Mediante este campo podremos hacer un seguimiento preciso del ticket, bien si acaba de ser creado, si ya ha sido asignado a un operador, si se encuentra a la espera de agentes externos, pendiente de cierre, si se ha reabierto o si ya se ha cerrado. Por defecto, se puede pasar de un estado a otro sin restricciones. Pero es posible que queramos concretar el flujo de estados durante el ciclo de vida del ticket.

Ejemplo: tenemos un equipo de operadores responsables de la gestión de incidencias de clientes. Para asegurarnos de que el orden de resolución es respetado y garantizar una calidad de servicio al cliente, mediante el mapeo de estados indicaremos que un ticket con estado Nuevo únicamente puede pasar a los estados Asignado o Pendiente de tercera persona; de cualquiera de estos tres estados únicamente podrá pasar a Pendiente de ser cerrado, y será desde éste desde el que pueda quedar finalmente Cerrado. Además, desde Cerrado la única posibilidad será volver a Reabierto. La configuración para este caso sería así:

Volver al índice de documentación de Pandora FMS