NexTool Solutions

Alguns processos sempre geram um chamado derivado - e cada vez que a etapa é esquecida, o processo falha em silêncio. O módulo Ticket Flow do NexTool transforma esse encadeamento em automação: quando um chamado atende a um critério, ele cria o chamado seguinte a partir de um modelo nativo do GLPI, sem intervenção humana.

O problema

Muitas categorias de chamado seguem sempre o mesmo roteiro. Quando abre um chamado de "Contratação de Serviço", deveria nascer automaticamente um de "Aprovação Financeira". Quando um chamado de "Manutenção" é solucionado, deveria surgir uma "Pesquisa de Qualidade". No GLPI padrão essa orquestração é feita na memória do técnico - quando lembrada. O resultado é conhecido: etapas puladas, processos incompletos e auditoria impossível, porque não existe registro dos subprocessos que deveriam ter sido abertos.

Vale ser honesto sobre o que o GLPI já faz. As regras de negócio de ticket (RuleTicket) são ótimas para roteirizar, atribuir e categorizar - mas elas agem sobre o próprio chamado que está sendo criado ou atualizado. Nenhuma regra nativa cria um chamado novo a partir de outro. É exatamente essa lacuna que o Ticket Flow preenche.

Como o Ticket Flow funciona

O módulo permite configurar fluxos que disparam a criação de um novo chamado quando um chamado original atende a um critério. Cada fluxo é vinculado a uma categoria ITIL e a um evento de gatilho, e usa os modelos de chamado nativos do GLPI para gerar o chamado derivado:

• 3 gatilhos configuráveis - chamado criado, chamado solucionado e chamado fechado. Cada categoria só admite um fluxo ativo, o que elimina ambiguidade sobre qual regra vale.
• Integração com TicketTemplate - o chamado filho nasce de um modelo nativo do GLPI, herdando categoria, título, descrição, grupos e prioridade já configurados no modelo.
• Motor via hooks nativos - a execução é automática pelos hooks item_add e item_update de Ticket, sem depender de cron nem de ação manual.
• Guarda anti-loop - um mecanismo interno impede que o chamado gerado dispare o motor de novo, cortando o risco de recursão infinita.
• Log de execução - cada acionamento é registrado com link para o chamado original e para o chamado gerado, criando rastreabilidade completa.
• Aba de teste - dá para simular a criação de um chamado a partir de um modelo na própria tela de configuração, antes de liberar o fluxo em produção.

Por que o modelo de chamado é o coração do fluxo

Como o chamado filho é gerado a partir de um TicketTemplate, a qualidade do fluxo depende inteiramente de como o modelo está preenchido. Antes de colocar um fluxo em produção, vale auditar os campos predefinidos dos seus modelos. A consulta abaixo lista modelos de chamado e seus campos predefinidos - se o campo de grupo ou de responsável estiver vazio, o filho nasce órfão:

-- Modelos de chamado e seus campos predefinidos.
-- O Ticket Flow copia esses valores no chamado filho.
-- Campo essencial em branco (grupo/responsavel) = filho orfao.
SELECT tt.id            AS modelo_id,
       tt.name          AS modelo,
       tp.num           AS campo_num,
       tp.value         AS valor_predefinido
FROM glpi_tickettemplates tt
LEFT JOIN glpi_tickettemplatepredefinedfields tp
       ON tp.tickettemplates_id = tt.id
ORDER BY tt.name, tp.num;

Cada linha é um campo predefinido do modelo. O valor de num é a opção de busca do GLPI (título, categoria, grupo requerente, grupo atribuído, prioridade). Um modelo sem grupo atribuído gera um chamado filho que ninguém enxerga na fila - e o processo trava exatamente onde deveria avançar.

Ticket Flow vs recursos nativos do GLPI

Como ativar

1. Instale o plugin NexTool no seu GLPI.
2. Acesse Configuração > NexTool > Módulos.
3. Ative o Ticket Flow e clique em Configurar.
4. Na aba Fluxos, crie um fluxo escolhendo a categoria, o gatilho e o modelo de chamado filho.
5. Ative o motor de automação na aba de configurações e valide o comportamento na aba de teste antes de produção.

Para quem é indicado - e quando não usar

O Ticket Flow é para equipes com processos estruturados, em que a abertura de um chamado é condição para outro começar: gestão de mudanças, contratações, projetos e processos de qualidade, onde esquecer uma etapa tem impacto real na operação e na auditoria.

Não é a ferramenta certa quando o que você precisa é encadear tarefas dentro do mesmo chamado (para isso existe fluxo de subtarefas), nem quando a lógica é simplesmente atribuir ou categorizar o próprio chamado - isso as regras de negócio nativas já resolvem. Ticket Flow ganha valor justamente quando um processo precisa gerar outro chamado, com dono e prazo próprios.

O que aprendemos sustentando isso

Na sustentação, o erro número um do Ticket Flow nunca está no motor: está no modelo de chamado filho sem grupo atribuído - o filho nasce sem dono e some da fila. O segundo é esquecer que só um fluxo por categoria fica ativo, então dois processos que dependem da mesma categoria brigam pela mesma vaga. O terceiro é o mais traiçoeiro: o gatilho "fechado" também dispara quando o GLPI fecha o chamado sozinho, pela rotina de fechamento automático por inatividade (o cron de autoclose). Já vimos um cliente amanhecer com uma leva de chamados filhos criados de madrugada, porque um lote de tickets antigos foi encerrado pela rotina e cada fechamento acionou o fluxo. A recomendação que padronizamos: reserve o gatilho "fechado" para processos que realmente devem rodar no encerramento, prefira "solucionado" quando a intenção é reagir à resolução, e sempre valide o modelo filho na aba de teste antes de ligar o motor.

Compatibilidade

• GLPI: 10.0+ e 11.0+
• Plano: PAID
• Plugin: NexTool 3.x+

O Ticket Flow faz parte do NexTool, ecossistema de módulos para expandir o GLPI sem customização de código. Fale com a equipe para uma demonstração.

Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.