Soporte y Workflow
Pandora ITSM permite controlar el flujo de trabajo de sus ticketspor medio de Reglas de Workflow (Workflow rules) y Mapeo de estados (Status mapping).
Reglas de Workflow
Menú Soporte → Flujo de trabajo → Reglas de flujo de trabajo (Support → Workflow → Workflow rules).
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, solamente los usuarios administradores (superadmin) podrán crear y editar estas reglas.
Los tickets que se comprobarán serán los abiertos, para comprobar también los tickets cerrados se debe activar el token en el menú Configuración → Configuración → Configuración de incidencias → Flujos de trabajo → Comprobar tickets cerrados cuando se ejecutan las reglas de flujo de trabajo (Setup → Setup → Issue setup → Workflows → Check closed tickets when running workflow rules).
Creación de reglas de flujo de trabajo
Menú Soporte → Flujo de trabajo → Reglas de flujo de trabajo → Crear (Support → Workflow → Workflow rules → Create).
Se debe colocar una descripción y un modo 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.
Condiciones
Al editar una regla de flujo de trabajo (haciendo clic en su descripción en la lista de reglas) se tendrá acceso también a la pestaña Condiciones (Conditions) las cuales podrán ser agregadas pulsando el botón Crear (Create), completando los parámetros en los campos del ticket y guardando con el botón correspondiente.
Dentro de cada condición existe un campo importante también denominado Condición el cual definirá cómo se aplicarán al resto de los campos de los filtros:
- Coincidir todos los campos (Match all fields).
- Coincidir cualquier campo (Match any field).
- Ninguna coincidencia (No match).
Algunos detalles de los campos de los filtros:
- Prioridad (Priority): Una superior numérica no engloba a las inferiores.
- Tipo de ticket (Ticket type): Al seleccionar un ítem que tenga campos personalizados estos aparecerán y se podrán hacer uso de ellos para añadirlos al conjunto de filtros de la condición.
Se pueden tener una o varias condiciones por regla. La relación por defecto entre cada una de las condiciones de una regla es OR
: con que se cumpla una, la regla se activará y ejecutará la acción o acciones programadas.
Dichas relaciones puede ser cambiadas y cada condición puede ser subida o bajada en la columna Acción (Action) en el orden de evaluación.
Acciones
El siguiente paso es crear la acción o acciones que han de llevarse cabo si se cumplen las condiciones elegidas. Dependiendo de del Tipo de acción (Action type) aparecerán debajo uno o más campos y subcampos a establecer, por ejemplo, si se escoge enviar mensaje de correo electrónico aparecerá “Para”, “Asunto” y “Texto”.
Las acciones a ejecutar al ticket son:
- Cambiar prioridad.
- Cambiar propietario.
- Cambiar grupo.
- Cambiar estado.
- Enviar correo electrónico.
- Añadir Unidad de Trabajo.
- Cambiar fecha de actualización.
- Cambiar resolución.
- Ejecutar un comando, ya se ejecutar un comando en el servidor o bien un script personalizado.
- Bloquear.
- Desbloquear.
- Cambiar el tipo.
Macros
Para configurar las acciones, se puede hacer uso de las macros. Estas se sustituirán por el valor correspondiente al del ticket.
_access_url_
: URL directa al ticket._author_
: Creador del ticket._creation_timestamp_
: Fecha y hora de la creación del ticket._fullname_
: Nombre completo del usuario que recibe el correo._id_group_
: ID del Grupo asignado al ticket._id_priority_
: ID de la prioridad del ticket._id_resolution_
: ID de la resolución del incidente._id_status_
: ID del Estado del incidente._incident_auth_email_
: Email del usuario creador del ticket._incident_closed_by_
: Usuario que cierra el ticket._incident_epilog_
: Epílogo del ticket._incident_group_email_
: Email del grupo asignado._incident_id_
: ID del ticket._incident_own_email_
: Email del usuario propietario._incident_title_
: Título del ticket._name_group_
: Nombre del grupo asignado al incidente._name_priority_
: Nombre de la prioridad del ticket._name_resolution_
: Nombre de la resolución del incidente._name_status_
: Nombre del Estado del incidente._owner_
: Propietario del ticket._sitename_
: Nombre del sitio, tal y como se haya definido en el setup._type_tickets_
: Tipo de ticket._update_timestamp_
: Última vez que se actualizó el ticket._username_
: Nombre identificador del usuario que recibe el correo (login name).- 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_
.
Mapeo de estados
Un ticket tiene numerosos campos. Quizás el más importante es el campo estado. Este campo se refiere a si un ticket, problema o cambio se da por cerrado, pendiente de un tercero, nuevo o recién creado, si está asignado, si se ha reabierto, si se ha verificado o si no se ha confirmado. Este ciclo está abierto al usuario y se puede pasar de uno a otro sin restricción por defecto.
En caso de necesitar definir el flujo se cuenta con la opción del Mapeo de estados, en la cual se pueden definir cuáles estados y resoluciones estarán disponibles para el usuario.
Existen determinadas circunstancias que actúan automáticamente cuando se pasa de un estado a otro. Al pasar de cualquier estado al estado «cerrado», automáticamente se activará una casilla de texto que antes no estaba accesible llamada «epílogo» que sirve para explicar cuál fue el resultado de la intervención o cambio o cual fue -en suma- la causa del problema y su solución.
Un ticket solucionado es la base para generar un artículo en la base de conocimiento que sirva para en posteriores ocasiones y así solucionar un problema de forma rápida y documentada.