Políticas de tiempo agotado
La política de tiempo de espera es un conjunto de reglas que definen lo que debe suceder cuando un elemento de la aplicación excede su estancia en un estado particular por más de las horas especificadas.
En los capítulos anteriores, creamos el flujo de trabajo y también definimos nuestros campos personalizados. Ahora, añadiremos algunas reglas de tiempo de espera.
Continuando con nuestra aplicación Bug, asumamos que nuestra compañía es estricta en el control de calidad y exige lo siguiente:
- Regla #1 Un nuevo fallo debe ser verificado dentro de las 48 horas. Si se trata de un fallo de alta prioridad, entonces debería ser verificado dentro de las 24 horas siguientes.
- Regla #2 Un fallo que ha sido marcado como arreglado debería ser probado dentro de las 72 horas después de que el fallo sea marcado como arreglado. Si se trata de un fallo de alta prioridad, entonces debería ser probado dentro de las 48 horas siguientes.
Añadir una política de tiempo de espera
Abra la pantalla de la lista de aplicaciones yendo a Menú Principal ▸ ▸ Admin ▸ Aplicaciones personalizadas ▸ Aplicaciones y haciendo clic en el para nuestra aplicación Bug. A continuación, haga clic en el botón Añadir ...botón.
Cuando en estado... | El estado del fallo en el que se aplica la regla. En nuestro caso, hemos definido las reglas para los estados Nuevo y Verificado porque el equipo de control de calidad es responsable en estos estados. |
... por horas (por prioridad) | Puede establecer las horas por prioridad. En nuestro caso, hemos establecido las horas según nuestras reglas #1 y #2. La opción Anular, si está marcada, significa que el usuario final que realiza la transición puede especificar cuándo se producirá el tiempo de espera. Tomemos un ejemplo de un sistema CRM. El ejecutivo de ventas, hace un seguimiento del prospecto cada 5 días. Sin embargo, en algunos casos, el prospecto puede estar de vacaciones y pedirle que haga un seguimiento después de, digamos, dos semanas. En ese caso, el ejecutivo de ventas, en el momento de marcar la consulta como "Seguimiento" puede especificar la siguiente fecha de seguimiento. |
Acción | La transición de estado a realizar después de que el tiempo expire. No necesitamos esto en nuestro ejemplo de seguimiento de fallos, pero tomemos el ejemplo de este flujo de trabajo del escritorio de ayuda. En este ejemplo, se puede desear que todos los tickets en estado Resuelto se muevan al estado Cerrado si no recibimos respuesta del cliente en 5 días. En ese caso pondríamos 5x24, es decir, 120 para todas las prioridades y elegiríamos la acción como Close. |
Marca como demorado | Esta opción marcará el Bug como Retrasado y notificará al asignatario y al administrador del estado. |