NexTool Solutions

No GLPI, a aprovação nativa é uma só ronda. Pede a validação a uma ou mais pessoas, define uma percentagem de aceitação e pronto - não existe um encadeamento hierárquico em que o departamento financeiro só é chamado depois de o chefe direto aprovar. O módulo Approval Flow da NexTool preenche exatamente essa lacuna.

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

Em ambientes empresariais, aprovar um pedido costuma abranger mais do que um nível: o chefe direto liberta, depois o financeiro valida o orçamento, depois a direção assina. É um fluxo sequencial - cada passo só faz sentido depois de o anterior ter aprovado. O GLPI não modela isto.

O que o core oferece é uma única ronda de validação. Abre o separador de aprovações, escolhe validadores (utilizadores ou grupos) e define o campo validation_percent - a percentagem de aprovações necessária para o pedido 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á um caminho distinto para quando alguém recusa.

Porque emular níveis com validation_percent não funciona

Na nossa atividade de suporte e manutenção, o desenho que mais aparece é a tentativa de forçar uma sequência com o campo de percentagem: a equipa pede validação a três pessoas e coloca 100%, à espera de uma cadeia. Não é. Os três recebem o pedido em simultâneo - a direção vê-o antes de o chefe direto ter sequer olhado. Pior: se um recusa, o pedido passa a REFUSED, mas os pedidos dos outros continuam pendentes na fila "as minhas validações", a entupir a vista de cada aprovador. E não há forma de dizer "se recusar, escala para outro nível" ou "se aprovar, fecha automaticamente com este modelo de solução". O habitual é a equipa abandonar a funcionalidade nativa e resolver a cadeia por e-mail, fora do sistema - o que mata a rastreabilidade e abre uma falha de auditoria.

Como funciona o Approval Flow

O módulo Approval Flow acrescenta fluxos de aprovação multinível ligados às categorias ITIL dos pedidos, reutilizando os próprios modelos de validação nativos do GLPI (ITILValidationTemplate) - assim, quem aprova continua a usar o separador de aprovações padrão, sem ecrã paralelo.

• Um fluxo por categoria ITIL - cada categoria tem no máximo um fluxo ativo, eliminando a ambiguidade sobre que regra se aplica a este pedido.
• Níveis encadeados em árvore - cada nível tem caminhos independentes para aprovação e recusa, por isso define desfechos diferentes por ramo.
• Ação configurável por desfecho - ao aprovar ou recusar, escolhe o que acontece: não fazer nada, resolver, fechar ou avançar para o nível seguinte.
• Solução padronizada - quando a ação é resolver ou fechar, a ligação a um SolutionTemplate é obrigatória, garantindo a mesma mensagem ao requerente em todos os pedidos.
• Disparo automático - ao criar um pedido numa categoria com fluxo ativo, a validação do primeiro nível é pedida sozinha, sem ninguém ter de se lembrar de abrir o separador de aprovações.
• Utilizadores ou grupos por nível - cada nível pode apontar para uma pessoa específica ou para um grupo, usando os mesmos destinos do validador nativo.

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

Antes de desenhar um fluxo, convém saber 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 pedido.
-- global_validation e status seguem CommonITILValidation:
--   1 = NONE     (não sujeito a aprovação)
--   2 = WAITING  (a aguardar)
--   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 ronda.
-- 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 já tenta simular níveis com vários validadores, a segunda consulta torna o problema evidente: várias linhas em status = 2 (WAITING) ao mesmo tempo, sem qualquer coluna que exprima ordem. É essa a lacuna que o fluxo encadeado resolve.

Como ativar

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

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

Faz sentido para organizações que precisam de governação formal de TI: pedidos de acesso, aquisições, alterações de infraestrutura, qualquer pedido que exija assinatura hierárquica com rastreabilidade dentro do próprio GLPI. Também para equipas que operam ITIL e não querem a cadeia de aprovação a viver numa caixa de correio.

Não vale a pena se a sua aprovação é de um só nível - nesse caso a validação nativa do GLPI já resolve, e acrescentar um fluxo encadeado só junta configuração sem ganho. Também não substitui um motor de BPM completo: o âmbito é a aprovação de pedidos, não a 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+

Passo seguinte

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

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