Building Blocks
Flujos de trabajo
El ciclo de vida de un ticket, configuration item o tarea — una secuencia de estados más las reglas sobre quién puede pasar de qué estado a cuál.
Actualizado el 23 ene 2026
Configuración · Building Blocks · 3.6
Un flujo de trabajo es un conjunto de estados + las transiciones entre ellos + quién puede ejecutar cada transición. Cada ticket, cada configuration item y cada tarea está vinculado a un tipo, y el flujo de trabajo cuelga de ese tipo. Flujos bien diseñados = un proceso claro; mal diseñados = «¿cuál es el estado real de este ticket?».
Por qué importa al negocio
«Nadie sabe cuándo algo está terminado»
Nombres de estado que el negocio entienda — no «Estado 3» o «Pendiente de revisión».
«Todo el mundo cierra cualquier ticket»
Las transiciones son específicas por rol — solo los managers cierran, los gestores resuelven.
«La aprobación vive en un Excel»
Estado de aprobación dentro del propio flujo de trabajo — incluyendo quién puede aprobar y qué viene después.
«Flujo distinto por tipo»
Una incidencia tiene pasos distintos a una solicitud de acceso — cada una tiene su propio flujo de trabajo.
El mecanismo
Tipo
Tipo de ticket, tipo de CI o tipo de tarea. Decide qué flujo de trabajo se aplica a un registro.
Estados
Las fases por las que pasa un registro. Un nuevo tipo viene con cuatro estados por defecto (ver más abajo).
Transiciones
Movimientos permitidos entre estados, más los grupos de autorización a los que se les permite ejecutarlos.
Los cuatro estados por defecto
Para cada nuevo tipo de ticket, CI o tarea, Gfacility crea cuatro estados automáticamente:
| Tipo de estado | Papel |
|---|---|
| Estado por defecto | Punto de partida. Cada nuevo registro aterriza aquí automáticamente. |
| Estado de aprobación | A la espera de aprobación. Opcional pero útil para flujos de cambio/finanzas. |
| Estado de cancelación | Retirado por el solicitante — no es lo mismo que rechazado. |
| Estado de rechazo | Rechazado por el gestor/aprobador. Estado final. |
Sobre estos cuatro puedes añadir libremente tus propios estados (En curso, Planificado, Bloqueado, A la espera del cliente, Resuelto, Verificado, …). Cada estado obtiene su propio color de texto y de fondo para reconocimiento visual.
¿Qué decisiones tomarás?
¿Cuántos estados por tipo?
Se recomienda entre 5 y 7. Más = confusión; menos = demasiado tosco para reporting.
¿Qué transiciones están permitidas?
Bloqueado → Resuelto está abierto a todos, pero Verificado → Reabierto solo al solicitante.
¿Qué grupo puede ejecutar qué transición?
Sale directamente de tu RACI: quien sea la «A» de un paso puede ejecutar la transición al siguiente estado.
¿Un flujo o uno por tipo?
Si los procesos difieren materialmente → flujo separado. Si no, un único flujo con variantes mediante campos personalizados.