Building Blocks
Campos personalizados
Añade campos de datos adicionales a tickets, CIs, ubicaciones, usuarios y organizaciones — sin código a medida, para que la estructura viva en la plataforma y no en el Excel de alguien.
Actualizado el 23 ene 2026
Configuración · Building Blocks · 3.2
Los campos personalizados (también llamados «campos configurables» o «campos libres») permiten capturar información específica de tu organización en tickets, configuration items, ubicaciones, usuarios y organizaciones — sin código a medida. Configúralos bien una vez y obtienes años de datos consistentes y reporting.
Por qué importa al negocio
«Quiero informar sobre X que no está en un campo estándar»
Los datos específicos de un sector (clase de amianto, zona ATEX, clasificación RGPD) viven en el registro, no en un Excel paralelo.
«Distintos tipos de ticket requieren distintas preguntas»
Una incidencia pregunta por «gravedad», una solicitud de acceso por «válido hasta». Campos personalizados por plantilla.
«Información obligatoria al crear»
Marca un campo como obligatorio y evitas tickets incompletos que de todas formas vuelven después.
«Enlace a otro objeto»
Un campo de lookup apunta directamente a otra entidad (proyecto, proveedor, activo) — sin texto libre.
Los dos tipos de campo
Campo estándar
Texto, número, fecha, desplegable, checkbox. Para valores autónomos que capturas en un registro. Funciona en todas partes: informes, filtros, exportaciones.
Campo de lookup
Referencia a otro objeto en Gfacility (p. ej. un proyecto, activo, usuario). Evita datos duplicados y errores tipográficos.
El mecanismo
Un campo siempre está acotado por módulo. Lo defines de forma centralizada y lo activas por módulo:
- Helpdesk y Configuration items: también por plantilla — un formulario de incidencia puede tener campos distintos a una solicitud de acceso.
- Ubicaciones · Usuarios · Organizaciones: un conjunto de campos por entidad — no por plantilla.
- Obligatorio/opcional y activo/inactivo: configurable, para retirar campos sin perder datos.
¿Qué decisiones tomarás?
¿Qué módulos llevan qué campos?
No todos los campos pertenecen a todas partes. Las decisiones deliberadas evitan la hinchazón de los formularios.
¿Estándar o lookup?
Si te refieres a datos existentes → lookup. Texto libre → estándar.
¿Obligatorio u opcional?
Obligatorio = calidad de datos pero añade fricción. Ante la duda pregúntate: ¿puedo seguir informando después si esto queda en blanco?
¿Específico por plantilla?
Para helpdesk/CI: acota los campos a plantillas concretas en lugar de a todo el módulo.