Los documentos que necesitan firma todavía circulan por correo y WhatsApp - sin trazabilidad, sin estado conocido y completamente desconectados de los tickets que los originaron. El módulo Autentique de NexTool trae ese flujo dentro de GLPI.
El problema
Contratos de prestación de servicios, términos de aceptación, autorizaciones de acceso, actas y rescisiones nacen de un proceso que ya está registrado en un ticket. Pero la firma ocurre fuera de él: alguien exporta el PDF, lo envía por correo, persigue al cliente por WhatsApp y, días después, intenta recordar dónde guardó la versión firmada. GLPI nativo sí almacena el archivo (pestaña Documentos, la tabla glpi_documents) y lo vincula al ticket, pero no tiene ninguna noción de firma: no sabe quién debe firmar, si ya firmó, ni guarda el rastro de evidencias. Cuando alguien pregunta "¿ese contrato se firmó?", la respuesta sigue siendo buscar en el correo y confiar en que el adjunto correcto siga ahí.
GLPI nativo frente al módulo Autentique
Conviene separar lo que GLPI hace por sí solo de lo que añade la integración. El núcleo de GLPI es excelente para adjuntar y versionar archivos, pero la firma electrónica nunca estuvo en su alcance:
| Necesidad | GLPI nativo | Con el módulo Autentique |
|---|---|---|
| Adjuntar un documento al ticket | Sí, en la pestaña Documentos | Sí, y lo envía a firma en el mismo flujo |
| Saber si el documento se firmó | No existe ese concepto | Estado por firmante en la pestaña del ticket |
| Actualización del estado | Manual (buscar en el correo) | Automática, por webhook |
| Rastro de evidencias | Inexistente | IP, fecha/hora y método por firmante (guardados en Autentique) |
| Validez jurídica | Depende de un proceso externo | Firma electrónica avanzada (Ley brasileña 14.063/2020) |
| Varios firmantes y orden | No aplica | Secuencial o simultáneo, con roles distintos |
| Entorno de pruebas | N/A | Modo sandbox, sin cargo |
Cómo funciona
El módulo Autentique integra GLPI con la plataforma de firma digital Autentique y concentra todo en una pestaña Firma Digital dentro del ticket. A partir de un documento ya adjunto, montas el sobre de firma sin cambiar de sistema:
- Envío directo desde el ticket - el PDF que ya está adjunto va a firma sin copiar archivos entre sistemas.
- Varios firmantes con roles - añade los que necesites con acciones distintas: Firmar, Aprobar, Atestiguar, Reconocer o Acusar recibo.
- Orden de firma - define si los firmantes firman en secuencia o de forma simultánea, según el proceso de la organización.
- Seguimiento en tiempo real - el estado de cada firmante se actualiza por webhook, sin consultar el panel de Autentique.
- Descarga del documento firmado - tras la última firma, el PDF final queda disponible en el propio ticket.
- Autenticación adicional - validación por SMS, selfie y otros métodos según la criticidad del documento.
- Modo sandbox - un entorno de pruebas para validar el flujo sin generar cargo en la plataforma.
Cómo el módulo habla con Autentique
La API de Autentique es GraphQL. Al enviar un documento, el módulo arma una mutation equivalente a esta, adjuntando el PDF del ticket y la lista de firmantes con la acción de cada uno:
# La API de Autentique es GraphQL. Al enviar un documento del ticket,
# el módulo arma una mutation como esta (el PDF va adjunto al request):
mutation CrearDocumento($doc: DocumentInput!, $signers: [SignerInput!]!, $archivo: Upload!) {
createDocument(sandbox: false, document: $doc, signers: $signers, file: $archivo) {
id
name
signatures {
public_id
email
action { name }
link { short_link }
}
}
}
# Variables, armadas a partir de la pestaña Firma Digital del ticket:
# {
# "doc": { "name": "Contrato de prestación de servicios - Ticket #1042" },
# "signers": [
# { "email": "cliente@empresa.com", "action": "SIGN" },
# { "email": "gestor@nextool.com", "action": "APPROVE" }
# ]
# }
El campo action mapea directamente los roles que eliges en la pestaña: SIGN (Firmar), APPROVE (Aprobar), SIGN_AS_A_WITNESS (Atestiguar), RECOGNIZE (Reconocer) y ACKNOWLEDGE (Acusar recibo). El public_id devuelto para cada firma es el identificador que ata al firmante con el ticket en los eventos siguientes.
El webhook, y lo que aprendimos dando soporte
El envío es solo la mitad del trabajo. La pieza que sostiene la trazabilidad es el webhook: en cada evento (firmó, aprobó, rechazó, visualizó), Autentique hace un POST a GLPI y la pestaña del ticket se actualiza sola. Operando esto para clientes, tres detalles ya nos costaron diagnóstico:
- El error más común no está en GLPI, está en Autentique. Quien olvida registrar la URL del webhook en el panel de la plataforma ve el documento enviarse y firmarse con normalidad, pero el estado nunca vuelve - y el ticket que llega a soporte es "¿por qué GLPI no muestra que se firmó?".
- Los webhooks se repiten. Si Autentique no recibe un 200 rápido, reenvía el mismo evento. Sin idempotencia, el mismo "firmó" entra dos veces en el historial. Por eso el procesamiento identifica el evento por el
public_idde la firma, no por el orden de llegada. - Entidad del documento. Al guardar el PDF firmado de vuelta en un ticket que vive en una subentidad, GLPI exige que el documento pertenezca a la misma entidad del ticket; si no, el vínculo
Document_Itemfalla en silencio y el archivo "se firma, pero desaparece". El módulo hereda la entidad del ticket al guardar el documento final.
Y, antes de ir a producción, siempre confirmamos que el sandbox está apagado. Dejarlo activo hace que la plataforma acepte el flujo sin generar una firma con validez real - el peor tipo de falso positivo en un proceso jurídico, porque todo parece funcionar hasta que alguien necesita el documento con valor legal.
Cómo activarlo
- Instala o actualiza NexTool en tu GLPI (10 u 11).
- Ve a Configuración > NexTool > Módulos.
- Activa Autentique y haz clic en Configurar.
- Indica el token de la API de Autentique y el secreto del webhook.
- Registra la URL del webhook en el panel de Autentique.
- Ejecuta un documento de extremo a extremo en modo sandbox antes de liberar en producción.
Para quién es - y cuándo no usarlo
El módulo encaja en departamentos de TI y equipos de operaciones que gestionan contratos de prestación de servicios, términos de uso de sistemas, autorizaciones de acceso y cualquier documento que necesite una firma con valor probatorio - sobre todo quienes ya usan Autentique y quieren eliminar la desconexión entre la firma y el ticket que la originó.
Cuándo no usarlo:
- Si solo necesitas una rúbrica en pantalla durante la atención presencial, sin plataforma externa ni costo por documento, un módulo de firma manual (signature pad) resuelve mejor.
- Si el documento exige firma calificada con certificado ICP-Brasil (A1/A3) - algunos actos regulados lo requieren - la firma avanzada puede no bastar; valida la exigencia legal antes.
- Si la empresa estandarizó otra plataforma distinta de Autentique, el módulo no aplica.
- Si el documento no nace de un ticket, la integración no aporta la trazabilidad que es su mayor valor.
Compatibilidad
- GLPI: 10.0+ y 11.0+
- Plan: Bajo demanda
- Plugin: NexTool 3.x+
Siguiente paso
Autentique forma parte de NexTool, un ecosistema de módulos para ampliar GLPI sin personalizaciones de código. Habla con el equipo para una demostración en tu escenario.
Este contenido se produjo con ayuda de inteligencia artificial y fue revisado por el equipo de NexTool Solutions.