En GLPI 11 el catálogo de servicios dejó de ser un plugin y pasó a formar parte del núcleo - pero lo que hunde a la mayoría de las implantaciones no es la falta de una función, sino un formulario publicado que ningún usuario logra ver. En el soporte de entornos GLPI de clientes, ese es el primer síntoma que aparece: "el catálogo está vacío" cuando, en la base de datos, los formularios existen y están activos. Esta guía muestra cómo montar un servicio de principio a fin con las funciones nativas y cómo diagnosticar las trampas antes de que el usuario se queje.
En GLPI 11 el catálogo es nativo - y tiene dirección propia
Hasta GLPI 10, catálogo de servicios era sinónimo de FormCreator. En GLPI 11 los formularios entraron en el núcleo y, con ellos, llegó un Catálogo de Servicios de verdad: una página self-service, servida por la ruta /ServiceCatalog, donde el usuario navega por los servicios organizados por categoría y abre el formulario correcto. Los formularios viven en Administración > Formularios y cada servicio del catálogo es un formulario con cuatro piezas que deben estar alineadas:
- Formulario (
glpi_forms_forms): el servicio en sí, con nombre, descripción y categoría. - Preguntas (
glpi_forms_questions): los campos que el usuario completa, con obligatoriedad y condiciones. - Control de acceso (
glpi_forms_accesscontrols_formaccesscontrols): quién ve el servicio en el catálogo. - Destino (
glpi_forms_destinations_formdestinations): lo que se crea al enviar - un ticket, un cambio o un problema.
Montar un servicio de principio a fin
El orden importa. Saltarse la pestaña de Control de acceso es el error que más retrabajo genera. Para cada servicio:
- Cree el formulario y asócielo a una categoría escueta (dos niveles como máximo;
glpi_forms_categorieses un árbol, y un árbol profundo se vuelve un laberinto). - Añada solo las preguntas que realmente vaya a usar en la atención. Un campo bonito que nadie lee en el ticket es fricción para el usuario.
- Configure el Control de acceso: la estrategia
AllowListrestringe el servicio a perfiles, grupos o usuarios;DirectAccessgenera un enlace directo (útil para un proveedor externo). Sin una política de acceso activa, el formulario no aparece en el catálogo. - Defina el Destino: el itemtype
FormDestinationTicketcrea un ticket; también existenFormDestinationChangeyFormDestinationProblem. En el destino mapea la categoría ITIL, el grupo responsable y el solicitante del ítem generado. - Active el formulario (
is_active) y pruébelo con un usuario self-service real, no con su cuenta de administrador.
La trampa que hace que el catálogo "desaparezca"
En soporte, el ticket recurrente es "publiqué el servicio y el usuario no lo ve". En casi todos los casos la causa es la misma: el formulario tiene is_active = 1, pero no tiene ninguna política de Control de acceso activa. GLPI 11 trata la visibilidad y la publicación como cosas separadas - publicar no basta, hace falta al menos una AllowList o DirectAccess activa. Y GLPI no emite ningún aviso: para el técnico el formulario está "en el aire", para el usuario el catálogo está vacío. Esta es la primera consulta que ejecutamos en un onboarding de soporte, antes de discutir la taxonomía:
-- Formularios PUBLICADOS que NO aparecen en el catalogo self-service:
-- estan activos (is_active=1) pero sin NINGUNA politica de acceso activa.
-- Existen, cuentan en el total y son invisibles para el usuario final.
SELECT f.id, f.name, f.usage_count
FROM glpi_forms_forms f
LEFT JOIN glpi_forms_accesscontrols_formaccesscontrols ac
ON ac.forms_forms_id = f.id
AND ac.is_active = 1
WHERE f.is_active = 1
AND f.is_deleted = 0
AND f.is_draft = 0
AND ac.id IS NULL
ORDER BY f.usage_count DESC;
Un detalle que solo muerde a quien migró de verdad: al llevar formularios de FormCreator al núcleo de GLPI 11, la visibilidad por perfil de FormCreator no se convierte automáticamente en una AllowList. El formulario llega activo, pero sin política de acceso - es decir, invisible. Hemos auditado catálogos recién migrados con decenas de servicios en ese limbo, y el cliente juraba que "la migración perdió los formularios". No los perdió: estaban ahí, solo que sin nadie que pudiera verlos.
Visión del cliente vs visión técnica: dónde vive cada una
El catálogo tiene dos capas y, en GLPI 11, están en lugares distintos del formulario:
- Visión del cliente vive en la pestaña Catálogo de servicios (título, descripción amigable, categoría, ilustración) y en el Control de acceso (quién ve). Es lo que aparece en
/ServiceCatalog. - Visión técnica vive en el Destino: categoría ITIL, grupo técnico y solicitante del ticket generado. El SLA no vive en el formulario - se aplica sobre el ticket creado, por una regla de negocio o por la categoría ITIL.
El error común aquí es intentar "poner el SLA en el formulario". Ese campo no existe: el formulario solo crea el ítem; quien carga el plazo es el ticket. La matriz que usamos para decidir la configuración de cada servicio:
| Servicio del catálogo | Control de acceso | Destino (itemtype) | De dónde viene el SLA |
|---|---|---|---|
| Solicitar acceso VPN (self-service) | AllowList: perfil Self-Service | FormDestinationTicket + categoría "Accesos" | Regla de negocio sobre la categoría |
| Abrir una petición de cambio (solo técnicos) | AllowList: perfil Técnico | FormDestinationChange | Flujo de cambio, no SLA de ticket |
| Formulario para un proveedor externo | DirectAccess (enlace/token) | FormDestinationTicket + entidad del proveedor | Regla por entidad |
| Servicio en construcción | Ninguna activa | - | Invisible - por intención, nunca por olvido |
Mida por el uso, no por el tamaño
Un buen catálogo no es un catálogo grande. Cada formulario de GLPI 11 tiene un contador nativo de uso (usage_count), incrementado en cada envío - úselo para priorizar y podar. Un servicio que nadie activa desde hace meses solo engorda el menú y hunde a los que importan. La consulta de poda que ejecutamos en nuestro ciclo trimestral de revisión:
-- Candidatos a poda: publicados hace mas de 90 dias y nunca usados.
-- Un menu escueto ayuda al usuario a encontrar el servicio correcto antes.
SELECT id, name, usage_count, date_creation
FROM glpi_forms_forms
WHERE is_active = 1
AND is_deleted = 0
AND usage_count = 0
AND date_creation < (NOW() - INTERVAL 90 DAY)
ORDER BY date_creation;
Empiece por los diez servicios más solicitados, use nombres que el usuario entienda ("Solicitar un portátil", no "Aprovisionamiento de activo") y revise el catálogo cada trimestre con el usage_count en la mano. Así el catálogo deja de ser un escaparate estático y se convierte en la puerta de entrada real del service desk.
¿Necesita estructurar (o rescatar) un catálogo de servicios en GLPI 11 con la visibilidad bajo control y los destinos mapeados a su flujo? Conozca los proyectos de implantación de NexTool.
Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.