I documenti da firmare circolano ancora via e-mail e WhatsApp - senza tracciabilità, senza uno stato noto e completamente scollegati dai ticket che li hanno originati. Il modulo Autentique di NexTool porta questo flusso dentro GLPI.
Il problema
Contratti di prestazione di servizi, termini di accettazione, autorizzazioni di accesso, verbali e risoluzioni nascono da un processo già registrato in un ticket. Ma la firma avviene al di fuori: qualcuno esporta il PDF, lo invia via e-mail, sollecita il cliente su WhatsApp e, giorni dopo, cerca di ricordare dove ha salvato la versione firmata. GLPI nativo memorizza sì il file (scheda Documenti, tabella glpi_documents) e lo collega al ticket, ma non ha alcuna nozione di firma: non sa chi deve firmare, se ha firmato, e non conserva la traccia delle prove. Quando qualcuno chiede "quel contratto è stato firmato?", la risposta resta cercare nell'e-mail sperando che l'allegato giusto sia ancora lì.
GLPI nativo rispetto al modulo Autentique
Conviene separare ciò che GLPI fa da solo da ciò che aggiunge l'integrazione. Il nucleo di GLPI è ottimo per allegare e versionare file, ma la firma elettronica non è mai stata nel suo perimetro:
| Esigenza | GLPI nativo | Con il modulo Autentique |
|---|---|---|
| Allegare un documento al ticket | Sì, nella scheda Documenti | Sì, e lo invia alla firma nello stesso flusso |
| Sapere se il documento è stato firmato | Il concetto non esiste | Stato per firmatario nella scheda del ticket |
| Aggiornamento dello stato | Manuale (cercare nell'e-mail) | Automatico, via webhook |
| Traccia delle prove | Inesistente | IP, data/ora e metodo per firmatario (conservati su Autentique) |
| Valore giuridico | Dipende da un processo esterno | Firma elettronica avanzata (legge brasiliana 14.063/2020) |
| Più firmatari e ordine | Non applicabile | Sequenziale o simultaneo, con ruoli distinti |
| Ambiente di test | N/D | Modalità sandbox, senza addebito |
Come funziona
Il modulo Autentique integra GLPI con la piattaforma di firma digitale Autentique e concentra tutto in una scheda Firma Digitale dentro il ticket. Partendo da un documento già allegato, componi la busta di firma senza cambiare sistema:
- Invio diretto dal ticket - il PDF già allegato va alla firma senza copiare file tra i sistemi.
- Più firmatari con ruoli - aggiungine quanti servono con azioni distinte: Firmare, Approvare, Testimoniare, Riconoscere o Accusare ricezione.
- Ordine di firma - definisci se i firmatari firmano in sequenza o contemporaneamente, secondo il processo dell'organizzazione.
- Monitoraggio in tempo reale - lo stato di ogni firmatario viene aggiornato via webhook, senza consultare il pannello di Autentique.
- Download del documento firmato - dopo l'ultima firma, il PDF finale è disponibile sul ticket stesso.
- Autenticazione aggiuntiva - validazione tramite SMS, selfie e altri metodi in base alla criticità del documento.
- Modalità sandbox - un ambiente di test per validare il flusso senza generare addebiti sulla piattaforma.
Come il modulo dialoga con Autentique
L'API di Autentique è in GraphQL. Inviando un documento, il modulo costruisce una mutation equivalente a questa, allegando il PDF del ticket e l'elenco dei firmatari con l'azione di ciascuno:
# L'API di Autentique è in GraphQL. Inviando un documento dal ticket,
# il modulo costruisce una mutation come questa (il PDF è allegato alla richiesta):
mutation CreaDocumento($doc: DocumentInput!, $signers: [SignerInput!]!, $file: Upload!) {
createDocument(sandbox: false, document: $doc, signers: $signers, file: $file) {
id
name
signatures {
public_id
email
action { name }
link { short_link }
}
}
}
# Variabili, costruite dalla scheda Firma Digitale del ticket:
# {
# "doc": { "name": "Contratto di prestazione di servizi - Ticket #1042" },
# "signers": [
# { "email": "cliente@azienda.com", "action": "SIGN" },
# { "email": "manager@nextool.com", "action": "APPROVE" }
# ]
# }
Il campo action corrisponde direttamente ai ruoli scelti nella scheda: SIGN (Firmare), APPROVE (Approvare), SIGN_AS_A_WITNESS (Testimoniare), RECOGNIZE (Riconoscere) e ACKNOWLEDGE (Accusare ricezione). Il public_id restituito per ogni firma è l'identificatore che lega il firmatario al ticket negli eventi successivi.
Il webhook, e cosa abbiamo imparato sul campo
L'invio è solo metà del lavoro. Il pezzo che sostiene la tracciabilità è il webhook: a ogni evento (firmato, approvato, rifiutato, visualizzato), Autentique fa un POST verso GLPI e la scheda del ticket si aggiorna da sola. Gestendo tutto questo per i clienti, tre dettagli ci sono già costati diagnosi:
- L'errore più comune non è in GLPI, è in Autentique. Chi dimentica di registrare l'URL del webhook nel pannello della piattaforma vede il documento inviarsi e firmarsi normalmente, ma lo stato non torna mai - e il ticket che arriva al supporto è "perché GLPI non mostra che è stato firmato?".
- I webhook si ripetono. Se Autentique non riceve un 200 rapido, rinvia lo stesso evento. Senza idempotenza, lo stesso "firmato" entra due volte nella cronologia. Per questo l'elaborazione identifica l'evento tramite il
public_iddella firma, non per ordine di arrivo. - Entità del documento. Riscrivendo il PDF firmato in un ticket che vive in una sotto-entità, GLPI esige che il documento appartenga alla stessa entità del ticket; altrimenti il collegamento
Document_Itemfallisce in silenzio e il file "si firma, ma sparisce". Il modulo eredita l'entità del ticket quando salva il documento finale.
E, prima di andare in produzione, verifichiamo sempre che la sandbox sia disattivata. Lasciarla attiva fa accettare il flusso alla piattaforma senza produrre una firma con valore reale - il peggior tipo di falso positivo in un processo giuridico, perché tutto sembra funzionare finché qualcuno non ha bisogno del documento con valore legale.
Come attivarlo
- Installa o aggiorna NexTool sul tuo GLPI (10 o 11).
- Vai su Configurazione > NexTool > Moduli.
- Attiva Autentique e clicca su Configura.
- Inserisci il token dell'API Autentique e il segreto del webhook.
- Registra l'URL del webhook nel pannello di Autentique.
- Esegui un documento end to end in modalità sandbox prima di rilasciare in produzione.
A chi è rivolto - e quando non usarlo
Il modulo è adatto a reparti IT e team operativi che gestiscono contratti di prestazione di servizi, termini d'uso dei sistemi, autorizzazioni di accesso e qualsiasi documento che richieda una firma con valore probatorio - soprattutto chi usa già Autentique e vuole eliminare lo scollegamento tra la firma e il ticket che l'ha originata.
Quando non usarlo:
- Se ti serve solo una sigla a schermo durante l'assistenza in presenza, senza piattaforma esterna né costo per documento, un modulo di firma manuale (signature pad) è più adatto.
- Se il documento richiede una firma qualificata con certificato ICP-Brasil (A1/A3) - alcuni atti regolamentati lo impongono - una firma avanzata potrebbe non bastare; verifica prima l'obbligo di legge.
- Se l'azienda ha standardizzato una piattaforma diversa da Autentique, il modulo non si applica.
- Se il documento non nasce da un ticket, l'integrazione non aggiunge la tracciabilità che è il suo maggior valore.
Compatibilità
- GLPI: 10.0+ e 11.0+
- Piano: Su richiesta
- Plugin: NexTool 3.x+
Prossimo passo
Autentique fa parte di NexTool, un ecosistema di moduli per estendere GLPI senza personalizzazioni di codice. Parla con il team per una demo nel tuo scenario.
Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team NexTool Solutions.