NexTool Solutions

Alguns processos geram sempre um ticket 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 automatização: quando um ticket cumpre um critério, cria o ticket seguinte a partir de um modelo nativo do GLPI, sem intervenção humana.

O problema

Muitas categorias de ticket seguem sempre o mesmo guião. Quando se abre um ticket de "Contratação de Serviço", devia nascer automaticamente um de "Aprovação Financeira". Quando um ticket de "Manutenção" é resolvido, devia surgir um "Inquérito de Qualidade". No GLPI de origem essa orquestração vive na memória do técnico - quando lembrada. O resultado é conhecido: etapas saltadas, processos incompletos e auditoria impossível, porque não existe registo dos subprocessos que se deviam ter aberto.

Sejamos honestos sobre o que o GLPI já faz. As regras de negócio de ticket (RuleTicket) são ótimas para encaminhar, atribuir e categorizar - mas atuam sobre o próprio ticket que está a ser criado ou atualizado. Nenhuma regra nativa cria um ticket novo a partir de outro. É exatamente essa a 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 ticket quando um ticket original cumpre um critério. Cada fluxo é ligado a uma categoria ITIL e a um evento de gatilho, e usa os modelos de ticket nativos do GLPI para gerar o ticket derivado:

• 3 gatilhos configuráveis - ticket criado, ticket resolvido e ticket fechado. Cada categoria só admite um fluxo ativo, o que elimina ambiguidade sobre qual regra vale.
• Integração com TicketTemplate - o ticket 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 ticket gerado dispare o motor de novo, cortando o risco de recursão infinita.
• Registo de execução - cada acionamento é registado com ligação para o ticket original e para o ticket gerado, criando rastreabilidade completa.
• Separador de teste - dá para simular a criação de um ticket a partir de um modelo no próprio ecrã de configuração, antes de disponibilizar o fluxo em produção.

Porque é que o modelo de ticket é o coração do fluxo

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

-- Modelos de ticket e os seus campos predefinidos.
-- O Ticket Flow copia estes valores no ticket 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 pesquisa do GLPI (título, categoria, grupo requerente, grupo atribuído, prioridade). Um modelo sem grupo atribuído gera um ticket filho que ninguém vê na fila - e o processo trava exatamente onde devia avançar.

Ticket Flow vs funcionalidades nativas do GLPI

Como ativar

1. Instale o plugin NexTool no seu GLPI.
2. Aceda a Configuração > NexTool > Módulos.
3. Ative o Ticket Flow e clique em Configurar.
4. No separador Fluxos, crie um fluxo escolhendo a categoria, o gatilho e o modelo do ticket filho.
5. Ative o motor de automatização no separador de configurações e valide o comportamento no separador de teste antes da produção.

Para quem é indicado - e quando não usar

O Ticket Flow é para equipas com processos estruturados onde abrir um ticket é 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 precisa é encadear tarefas dentro do mesmo ticket (para isso existe um fluxo de subtarefas), nem quando a lógica é simplesmente atribuir ou categorizar o próprio ticket - isso as regras de negócio nativas já resolvem. O Ticket Flow ganha valor precisamente quando um processo tem de gerar outro ticket, com dono e prazo próprios.

O que aprendemos a sustentar isto

Na sustentação, o erro número um do Ticket Flow nunca está no motor: está no modelo do ticket filho sem grupo atribuído - o filho nasce sem dono e desaparece da fila. O segundo é esquecer que só um fluxo por categoria fica ativo, por isso dois processos que dependem da mesma categoria disputam a mesma vaga. O terceiro é o mais traiçoeiro: o gatilho "fechado" também dispara quando o GLPI fecha o ticket sozinho, pela rotina de fecho automático por inatividade (o cron de autoclose). Já vimos um cliente acordar com um lote de tickets filhos criados de madrugada, porque um conjunto de tickets antigos foi encerrado pela rotina e cada fecho acionou o fluxo. A recomendação que padronizámos: reserve o gatilho "fechado" para processos que realmente devam correr no fecho, prefira "resolvido" quando a intenção é reagir à resolução, e valide sempre o modelo filho no separador 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 personalização de código. Fale com a equipa para uma demonstração.

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