Encadeamento automático de subtarefas no GLPI com SubTask Flow

Encadeie etapas de atendimento no GLPI: ao concluir uma tarefa, o SubTask Flow cria a próxima automaticamente conforme a solução escolhida. Configuração por template, proteção contra ciclos e SQL de auditoria.

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:

  1. Identifica os modelos filhos vinculados àquela solução;
  2. Cria as TicketTasks filhas na timeline do mesmo chamado;
  3. 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

  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.
  4. Garanta que todo modelo filho tenha grupo ou técnico responsável e tempo estimado preenchidos - esse é o campo que mais causa dor depois.
  5. 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)

AbordagemQuando usarLimite
Tarefa avulsa (manual)Processos ad-hoc, baixo volume, sem repetiçãoNão padroniza nem rastreia
Modelo de tarefa nativoUm passo repetido com conteúdo fixoNão encadeia o passo seguinte
SubTask FlowSequência condicional de tarefas dentro do mesmo chamado, disparada pela soluçãoEscopo é o ticket; não abre chamados novos
Projeto GLPIEntrega com marcos, múltiplos chamados, Gantt e prazosOverhead alto para um fluxo curto
Regras de negócioRoteamento e atribuição na abertura do chamadoNã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.

Perguntas Frequentes

Não. O GLPI oferece modelos de tarefa (TaskTemplates) para padronizar o conteúdo de cada passo, mas não dispara automaticamente o próximo. O SubTask Flow adiciona a relação pai-filho entre templates, para que concluir uma tarefa crie a seguinte.

Sim. O disparo acontece quando o técnico marca a tarefa como Feito e escolhe a solução. As subtarefas filhas são criadas na mesma timeline do chamado, sem esperar cron nem processo externo.

O módulo roda uma busca em profundidade (DFS) sobre o grafo de modelos antes de aceitar um vínculo. Se o novo vínculo fechar um ciclo (A gera B, B gera A), ele é rejeitado com mensagem explicativa no cadastro.

Quase sempre a solução escolhida não bate com a configurada no vínculo - diferença de maiúsculas/minúsculas ou de nome - ou nenhum modelo filho está vinculado àquela solução. Padronize as soluções como vocabulário controlado e confira o modelo pai.

Use a aba de registros do módulo para ver pai, filho, solução, técnico e horários. Para monitorar higiene, rode SQL sobre glpi_tickettasks e glpi_tasktemplates filtrando por state e por responsável vazio, identificando tarefas órfãs.

Precisa de ajuda?