Building Blocks
Workflows
O ciclo de vida de um ticket, configuration item ou tarefa — uma sequência de estados mais as regras que definem quem pode mover de que estado para qual.
Atualizado em 23/01/2026
Configuração · Building Blocks · 3.6
Um workflow é um conjunto de estados + as transições entre eles + quem pode realizar cada transição. Cada ticket, cada configuration item, cada tarefa está ligado a um tipo, e o workflow está associado a esse tipo. Workflows bem desenhados = um fluxo de processo claro; mal desenhados = “afinal qual é o estado deste ticket?”.
Porque é que isto importa para o negócio
"Ninguém sabe quando algo está terminado"
Nomes de estado que o negócio compreende — não "Estado 3" ou "Pending review".
"Toda a gente fecha qualquer ticket"
As transições são específicas por papel — só os gestores podem fechar, os tratadores podem resolver.
"As aprovações vivem num Excel"
Estado de aprovação dentro do próprio workflow — incluindo quem pode aprovar e o que vem a seguir.
"Fluxo diferente por tipo"
Um incidente tem passos diferentes de um pedido de acesso — cada um com o seu workflow.
O mecanismo
Tipo
Tipo de ticket, tipo de CI ou tipo de tarefa. Decide que workflow se aplica a um registo.
Estados
As fases pelas quais um registo passa. Um novo tipo é criado com quatro estados padrão (ver abaixo).
Transições
Movimentos permitidos entre estados, mais quais os grupos de autorização autorizados a executá-los.
Os quatro estados padrão
Para cada novo tipo de ticket, CI ou tarefa, o Gfacility cria automaticamente quatro estados:
| Tipo de estado | Papel |
|---|---|
| Estado por omissão | Ponto de partida. Cada novo registo aterra aqui automaticamente. |
| Estado de aprovação | A aguardar aprovação. Opcional, mas útil para fluxos de change/financeiros. |
| Estado de cancelamento | Retirado pelo requerente — não é o mesmo que rejeitado. |
| Estado de rejeição | Recusado pelo tratador/aprovador. Estado final. |
Para além destes quatro, pode acrescentar livremente os seus próprios estados (Em curso, Agendado, Bloqueado, A aguardar cliente, Resolvido, Verificado, …). Cada estado tem a sua cor de texto e cor de fundo para reconhecimento visual.
Que decisões irá tomar?
Quantos estados por tipo?
5–7 é o recomendado. Mais = confusão; menos = demasiado grosso para reporting.
Que transições são permitidas?
Bloqueado → Resolvido está aberto a todos, mas Verificado → Reaberto apenas ao requerente.
Que grupo pode realizar que transição?
Decorre diretamente do seu RACI: quem é o "A" para um passo, pode executar a transição para o estado seguinte.
Um workflow ou por tipo?
Se os processos diferem materialmente → workflow separado. Caso contrário, um workflow com variantes via campos personalizados.