NexTool Solutions

Os processos de TI raramente cabem num único passo. O diagnóstico leva à execução, a execução leva à validação, e cada etapa só faz sentido depois do resultado da anterior. No GLPI de origem, cada uma dessas tarefas nasce da digitação manual do técnico, o que inviabiliza a padronização assim que o volume cresce. O módulo SubTask Flow encadeia estas etapas: ao concluir uma tarefa, a seguinte é criada automaticamente conforme a solução escolhida.

Porque criar a próxima tarefa à mão não escala

Muitos fluxos de atendimento são previsíveis: analisar, executar, validar, comunicar. O GLPI oferece modelos de tarefa (TaskTemplates) para padronizar o conteúdo de cada passo, mas não sabe que um passo deve gerar o seguinte. O resultado é conhecido: o técnico abre o modelo certo, copia o responsável e o prazo, e cria a tarefa seguinte à mão. Num ambiente com dezenas de técnicos, isto produz três problemas crónicos: etapas esquecidas, dados divergentes entre tickets equivalentes e nenhuma rastreabilidade de "porque é que esta tarefa existe". Quando uma auditoria pergunta se a validação foi feita, a resposta depende da disciplina individual de cada técnico, não de um processo desenhado.

Como o SubTask Flow encadeia tarefas por solução

O módulo cria relações hierárquicas entre TaskTemplates. Um modelo pai aponta para um ou mais modelos filhos, e cada filho pode ser condicionado a uma solução específica. Quando o técnico marca a tarefa pai como "Feito" e escolhe a solução, o módulo executa três passos:

1. Identifica os modelos filhos ligados a essa solução;
2. Cria as TicketTasks filhas na cronologia do mesmo ticket;
3. Copia conteúdo, categoria, tempo estimado e responsável definidos no modelo filho.

A configuração vive no modelo, não no ticket. Ajusta o fluxo uma vez e ele passa a valer para todos os tickets que usam esse modelo, sem tocar em regras de negócio nem em automatizações externas. É a diferença entre documentar um processo e fazer com que o sistema o execute.

Passo a passo da configuração

1. Padronize a lista de soluções na configuração do módulo (por exemplo: "hardware", "software", "sem defeito"). Trate-a como um vocabulário fechado, não como texto livre.
2. Abra o TaskTemplate pai e ligue os modelos filhos no separador de encadeamento.
3. Para cada filho, defina qual solução o dispara.
4. Garanta que todo o modelo filho tem grupo ou técnico responsável e tempo estimado preenchidos - é o campo que mais custa depois.
5. Teste num ticket de homologação antes de disponibilizar em produção: conclua a tarefa pai, escolha cada solução possível e confirme que o filho certo nasce com os dados corretos.

Proteção contra ciclos

Encadeamento sem travão torna-se uma armadilha. Um modelo A que gera B, que gera C, que volta a A, criaria tarefas indefinidamente e bloquearia a cronologia do ticket. Antes de aceitar uma nova ligação, o módulo executa uma pesquisa em profundidade (DFS) sobre o grafo de modelos. Se a ligação fechar um ciclo, é rejeitada com uma mensagem explicativa, em vez de deixar o problema rebentar em produção. Vale a mesma disciplina de qualquer automatização: manter as cadeias curtas e legíveis facilita o diagnóstico quando algo foge ao esperado.

Rastreabilidade: o separador de registos

Automatização sem registo é uma caixa negra. O SubTask Flow mantém um histórico de execuções com o modelo pai, o modelo filho gerado, a solução escolhida, o técnico responsável e as marcas temporais. Numa auditoria, isto responde à pergunta mais frequente - "esta subtarefa foi criada por uma pessoa ou pelo fluxo, e a partir de que decisão?" - sem depender da memória de ninguém. É também o primeiro sítio a olhar quando um cliente reporta que "a etapa desapareceu": o registo mostra se o gatilho disparou e com que solução.

Diagnóstico: auditar o fluxo em SQL

Automatização silenciosa exige monitorização ativa. A consulta seguinte lista subtarefas ainda abertas que nasceram sem responsável definido, o sintoma clássico de um modelo filho incompleto. Execute numa réplica de leitura ou numa janela de baixa utilização:

-- Subtarefas abertas (state=1) sem tecnico nem grupo responsavel.
-- Sinaliza um TaskTemplate filho com users_id_tech/groups_id_tech vazio.
SELECT t.id                       AS ticket,
       tt.id                      AS task_id,
       tmpl.name                  AS modelo,
       tt.state,
       tt.users_id_tech,
       tt.groups_id_tech,
       tt.date_creation
FROM glpi_tickettasks tt
JOIN glpi_tickets t               ON t.id  = tt.tickets_id
LEFT JOIN glpi_tasktemplates tmpl ON tmpl.id = tt.tasktemplates_id
WHERE tt.state = 1
  AND tt.users_id_tech  = 0
  AND tt.groups_id_tech = 0
  AND t.is_deleted = 0
ORDER BY tt.date_creation DESC
LIMIT 200;

No GLPI, state = 1 é "Por fazer" e state = 2 é "Feito". Se esta lista cresce a cada semana, o problema não é o módulo: é um modelo filho publicado sem responsável, a gerar tarefas que ninguém vê na fila.

Quando usar (e quando não usar)

O erro de campo mais comum

Na sustentação de ambientes com muitos técnicos, o problema que mais aparece não é técnico, é de modelação. Alguém configura o filho para disparar na solução "Hardware", mas a opção que o técnico realmente seleciona no ecrã é "hardware" em minúsculas - ou "HW", num ambiente que herdou o vocabulário de outra ferramenta. O gatilho não corresponde, a subtarefa não nasce, ninguém recebe erro, e o passo de execução desaparece simplesmente do processo sem deixar rasto visível. A correção que padronizámos: tratar as cadeias de solução como vocabulário controlado, todas em minúsculas, documentadas num único mapeamento, e rever os modelos filhos sempre que alguém adiciona uma solução nova. O segundo erro recorrente é o modelo filho sem responsável: a tarefa nasce órfã, perde-se no meio da cronologia e só reaparece quando o SLA já foi ultrapassado. Por isso a consulta SQL acima entra na checklist de sustentação, não numa auditoria pontual.

A NexTool implementa e sustenta ambientes GLPI com automatizações como o SubTask Flow desenhadas para a operação real de cada cliente. Fale com a nossa equipa para mapear e automatizar o fluxo de tarefas da sua equipa.

Este conteúdo foi produzido com o apoio de inteligência artificial e revisto pela equipa Nextool Solutions.