NexTool Solutions

No GLPI, a aprovação nativa é uma rodada só. Você pede a validação de uma ou mais pessoas, define um percentual de aceite e pronto - não existe encadeamento hierárquico em que o financeiro só é acionado depois que o gestor imediato aprovou. O módulo Approval Flow do NexTool preenche exatamente essa lacuna.

O problema: aprovação hierárquica não existe no nativo

Em ambientes corporativos, aprovar um chamado costuma envolver mais de um nível: o gestor imediato libera, depois o financeiro valida o orçamento, depois a diretoria assina embaixo. É um fluxo sequencial - cada etapa só faz sentido depois que a anterior aprovou. O GLPI não modela isso.

O que o núcleo oferece é uma única rodada de validação. Você abre a aba de aprovações, escolhe validadores (usuários ou grupos) e define o campo validation_percent - o percentual de aprovações necessário para o chamado ser considerado validado. Todos os validadores recebem o pedido ao mesmo tempo. Não há ordem, não há "o nível 2 só dispara se o nível 1 aprovar", não há caminho diferente para quando alguém recusa.

Por que emular níveis com validation_percent não funciona

Na sustentação, o desenho que mais aparece é a tentativa de forçar uma sequência com o campo de percentual: a equipe pede validação de três pessoas e coloca 100%, imaginando que isso vira uma cadeia. Não vira. Os três recebem a solicitação ao mesmo tempo - a diretoria enxerga o pedido antes de o gestor imediato ter olhado. Pior: se um recusa, o chamado vai para REFUSED, mas os pedidos dos outros continuam pendentes na fila "minhas validações" deles, poluindo a visão de cada aprovador. E não há como dizer "se recusar, escale para outro nível" ou "se aprovar, feche automaticamente com este modelo de solução". O comum é a equipe abandonar o recurso nativo e resolver a cadeia por e-mail, fora do sistema - o que mata a rastreabilidade e abre brecha de auditoria.

Como o Approval Flow funciona

O módulo Approval Flow adiciona fluxos de aprovação multinível amarrados às categorias ITIL dos chamados, reaproveitando os próprios modelos de validação nativos do GLPI (ITILValidationTemplate) - ou seja, quem valida continua usando a aba de aprovações padrão, sem tela paralela.

• Um fluxo por categoria ITIL - cada categoria tem no máximo um fluxo ativo, eliminando a ambiguidade sobre qual regra se aplica a este chamado.
• Níveis encadeados em árvore - cada nível tem caminhos independentes para aprovação e recusa, então você define desfechos diferentes para cada ramo.
• Ação configurável por desfecho - ao aprovar ou recusar, você escolhe o que acontece: não fazer nada, solucionar, fechar ou avançar para o próximo nível.
• Solução padronizada - quando a ação é solucionar ou fechar, o vínculo a um SolutionTemplate é obrigatório, garantindo a mesma mensagem ao solicitante em todos os chamados.
• Disparo automático - ao criar um chamado numa categoria com fluxo ativo, a validação do primeiro nível é solicitada sozinha, sem alguém precisar lembrar de abrir a aba de aprovações.
• Usuários ou grupos por nível - cada nível pode apontar para uma pessoa específica ou para um grupo, usando os mesmos alvos do validador nativo.

Diagnóstico: onde ler o estado da aprovação

Antes de desenhar um fluxo, vale entender onde o GLPI guarda o estado nativo - é isso que o módulo orquestra por baixo. Duas consultas resolvem a leitura:

-- GLPI: inspecionar o estado de validação nativo de um chamado.
-- global_validation e status seguem CommonITILValidation:
--   1 = NONE     (não sujeito a aprovação)
--   2 = WAITING  (aguardando)
--   3 = ACCEPTED (aprovado)
--   4 = REFUSED  (recusado)

SELECT id, name, global_validation, validation_percent
FROM glpi_tickets
WHERE id = 12345;

-- Pedidos individuais: no nativo são todos "pares" na MESMA rodada.
-- Não existe coluna de "nível" nem ordem hierárquica.
SELECT tickets_id, status, submission_date, validation_date
FROM glpi_ticketvalidations
WHERE tickets_id = 12345
ORDER BY submission_date;

Se você já tenta simular níveis com vários validadores, a segunda consulta deixa o problema evidente: várias linhas em status = 2 (WAITING) ao mesmo tempo, sem qualquer coluna que expresse ordem. É essa a lacuna que o fluxo encadeado resolve.

Como ativar

1. Instale o NexTool no seu GLPI (10.0+ ou 11.0+).
2. Acesse Configuração > NexTool > Módulos.
3. Ative o Approval Flow e clique em Configurar.
4. Na aba Fluxos, crie um fluxo e associe-o à categoria ITIL desejada.
5. Defina os níveis, os aprovadores (usuário ou grupo) e a ação de cada desfecho (aprovar/recusar).
6. Para ações de solucionar ou fechar, vincule o SolutionTemplate correspondente.

Para quem é indicado (e quando não usar)

Faz sentido para organizações que precisam de governança formal em TI: solicitações de acesso, aquisições, mudanças de infraestrutura, qualquer chamado que exija assinatura hierárquica com rastreabilidade dentro do próprio GLPI. Também para times que operam ITIL e não querem a cadeia de aprovação vivendo em caixa de e-mail.

Não vale a pena se a sua aprovação é de um nível só - nesse caso a validação nativa do GLPI já resolve, e adicionar um fluxo encadeado só acrescenta configuração sem ganho. Também não substitui um motor de BPM completo: o escopo é aprovação de chamados, não orquestração de processos arbitrários com formulários e integrações externas.

Compatibilidade

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

Próximo passo

O Approval Flow faz parte do NexTool, ecossistema de módulos que expande o GLPI sem customização de código no core. Fale com a equipe para ver o fluxo multinível funcionando no seu cenário.

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