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: ao concluir uma tarefa, a próxima é criada automaticamente conforme a solução escolhida.
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 marca a tarefa pai como "Feito" e escolhe a solução, o módulo executa três passos:
- Identifica os modelos filhos vinculados àquela solução;
- Cria as TicketTasks filhas na timeline do mesmo chamado;
- Copia conteúdo, categoria, tempo estimado e responsável 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
- 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.
- Abra o TaskTemplate pai e vincule os modelos filhos na aba de encadeamento.
- Para cada filho, defina qual solução o dispara.
- Garanta que todo modelo filho tenha grupo ou técnico responsável e tempo estimado preenchidos - esse é o campo que mais causa dor depois.
- Teste em um chamado de homologação antes de liberar em produção: conclua a tarefa pai, escolha cada solução possível e confirme que a filha certa nasce com os dados corretos.
Proteção contra ciclos
Encadeamento sem trava vira armadilha. Um modelo A que gera B, que gera C, que volta para A, criaria tarefas indefinidamente e travaria a timeline do chamado. Antes de aceitar um novo vínculo, o módulo roda uma busca em profundidade (DFS) sobre o grafo de modelos. Se o vínculo fechar um ciclo, ele é rejeitado com mensagem explicativa, em vez de deixar o problema explodir em produção. 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 modelo pai, o modelo filho gerado, a solução escolhida, o técnico responsável 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 decisão?" - 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 com qual solução.
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)
| Abordagem | Quando usar | Limite |
|---|---|---|
| Tarefa avulsa (manual) | Processos ad-hoc, baixo volume, sem repetição | Não padroniza nem rastreia |
| Modelo de tarefa nativo | Um passo repetido com conteúdo fixo | Não encadeia o passo seguinte |
| SubTask Flow | Sequência condicional de tarefas dentro do mesmo chamado, disparada pela solução | Escopo é o ticket; não abre chamados novos |
| Projeto GLPI | Entrega com marcos, múltiplos chamados, Gantt e prazos | Overhead alto para um fluxo curto |
| Regras de negócio | Roteamento e atribuição na abertura do chamado | Não gerencia passos após a abertura |
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.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.