NexTool Solutions

Processos de TI raramente cabem em um único passo. Diagnóstico leva à execução, execução leva à validação, e cada etapa só faz sentido depois do resultado da anterior. No GLPI padrão, 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 essas etapas: quando o técnico registra a solução de uma tarefa na timeline, a próxima é criada automaticamente conforme essa resposta.

Por que criar a próxima tarefa na 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 ele não sabe que um passo deve gerar o próximo. O resultado é conhecido: o técnico abre o modelo certo, copia responsável e prazo, e cria a tarefa seguinte na unha. Em um ambiente com dezenas de técnicos, isso produz três problemas crônicos: etapas esquecidas, dados divergentes entre chamados equivalentes e nenhuma rastreabilidade de "por 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 registra a solução na timeline da tarefa pai (ou, se o modelo não tem condição, marca a tarefa como "Feito"), o módulo executa três passos:

1. Identifica os modelos filhos vinculados àquela solução;
2. Cria as TicketTasks filhas na timeline do mesmo chamado;
3. Copia conteúdo, categoria, duração e responsável (técnico e grupo) definidos no modelo filho.

A configuração vive no template, não no chamado. Você ajusta o fluxo uma vez e ele passa a valer para todos os tickets que usam aquele modelo, sem tocar em regras de negócio nem em automações externas. É a diferença entre documentar um processo e fazer o sistema executá-lo.

Passo a passo de configuração

1. Padronize a lista de soluções na configuração do módulo (por exemplo: "hardware", "software", "sem defeito"). Trate-as como um vocabulário fechado, não como texto livre.
2. Abra o TaskTemplate pai e vincule os modelos filhos na aba de encadeamento.
3. Para cada filho, defina qual solução o dispara. Um filho condicional exige que o modelo pai tenha o estado padrão "Informação".
4. Garanta que todo modelo filho tenha grupo ou técnico responsável e duração preenchidos - esse é o campo que mais causa dor depois.
5. Teste em um chamado de homologação antes de liberar em produção: crie uma tarefa pai de teste para cada solução possível, registre a solução na timeline e confirme que a filha certa nasce com os dados corretos.

Detecção de ciclos

Encadeamento sem trava vira armadilha. Um modelo A que gera B, que gera C, que volta para A, recriaria as mesmas tarefas a cada volta, e o fluxo nunca terminaria. Ao gravar um novo vínculo, o módulo roda uma busca em profundidade (DFS) sobre o grafo de modelos. Se encontrar um ciclo, ele mostra um aviso com o caminho do laço, mas o vínculo fica gravado: cabe a quem configura removê-lo. Só o vínculo de um modelo com ele mesmo é bloqueado. Por isso vale a disciplina de qualquer automação: manter as cadeias curtas e legíveis facilita o diagnóstico quando algo foge do esperado.

Rastreabilidade: a aba de registros

Automação sem registro é caixa-preta. O SubTask Flow mantém um histórico de execuções com o chamado, a tarefa pai, a tarefa filha gerada, quem disparou, quem concluiu e os timestamps. Numa auditoria, isso responde à pergunta que mais aparece - "esta subtarefa foi criada por alguém ou pelo fluxo, e a partir de qual tarefa?" - sem depender da memória de ninguém. Também é o primeiro lugar para olhar quando um cliente relata que "a etapa sumiu": o registro mostra se o gatilho disparou e a partir de qual tarefa.

Diagnóstico: auditando o fluxo em SQL

Automação silenciosa exige monitoramento ativo. A consulta abaixo lista subtarefas ainda em aberto que nasceram sem responsável definido, o sintoma clássico de um modelo filho incompleto. Rode em réplica de leitura ou em janela de baixo uso:

-- Subtarefas em aberto (state=1) sem tecnico nem grupo responsavel.
-- Sinaliza TaskTemplate filho sem users_id_tech/groups_id_tech preenchido.
SELECT t.id                       AS chamado,
       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 é "Para fazer" e state = 2 é "Feito". Se essa lista cresce a cada semana, o problema não é o módulo: é um modelo filho publicado sem responsável, gerando tarefas que ninguém enxerga 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 modelagem. Alguém configura o filho para disparar na solução "Hardware", mas a opção que o técnico realmente seleciona na tela é "hardware" em minúsculas - ou "HW", num ambiente que herdou o vocabulário de outra ferramenta. O gatilho não casa, a subtarefa não nasce, ninguém recebe erro, e a etapa de execução simplesmente desaparece do processo sem deixar rastro visível. A correção que padronizamos: tratar as strings de solução como vocabulário controlado, todas em minúsculas, documentadas em um de-para único, e revisar os modelos filhos toda vez que alguém adiciona uma solução nova. O segundo erro recorrente é o modelo filho sem responsável: a tarefa nasce órfã, some no meio da timeline e só reaparece quando o SLA já estourou. Por isso a consulta SQL acima entra no checklist de sustentação, não em uma auditoria pontual.

A NexTool implanta e sustenta ambientes GLPI com automações como o SubTask Flow desenhadas para a operação real de cada cliente. Fale com a nossa equipe para mapear e automatizar o fluxo de tarefas do seu time.

Revisado pela equipe NexTool Solutions.