Los custom fields de GoHighLevel empiezan siendo la solución y, sin gobernanza, terminan siendo el problema. El día uno creas «Plan contratado» y resuelves una necesidad real. Dos años después, la subcuenta acumula más de cien campos (en una implementación real que audité, el inventario llegó a 133), con duplicados que compiten («Plan», «plan_actual», «Plan Contratado 2»), campos huérfanos que nadie llena desde 2024, y fichas de contacto que exigen scroll arqueológico para encontrar el teléfono. Nadie decidió ese desorden: se acumuló, campo a campo, cada uno razonable en su momento.
Este artículo es la guía de custom fields A ESCALA: los límites prácticos que importan (que son de operación, no de plataforma), las reglas de gobernanza que evitan la degradación, la frontera exacta donde un dato deja de ser un campo y se convierte en una tabla externa, y cómo se limpia un inventario ya degradado sin romper las automatizaciones que cuelgan de él.
Respuesta rápida
- El límite real no es técnico: la plataforma aguanta cientos de campos; tu operación no. La degradación aparece por duplicados, huérfanos y fichas ilegibles mucho antes que cualquier tope del sistema.
- Las tres reglas de gobernanza: convención de nombres desde el día uno, un inventario con dueño y propósito por campo, y alta controlada (crear un campo es una decisión, no un reflejo).
- La frontera del dato: si el valor se consulta y ramifica workflows, es un custom field; si tiene historial, estructura o se calcula con reglas, es una tabla externa que proyecta su resultado a un campo.
- La limpieza segura: auditar uso real (workflows, formularios, vistas), fusionar duplicados con migración de datos, y despoblar huérfanos por etapas, nunca por borrado masivo de fin de semana.
| Señal en tu subcuenta | Diagnóstico | Remedio |
|---|---|---|
| Dos campos con el mismo dato en formatos distintos | Duplicación por alta sin inventario | Fusión con migración y redirección de workflows |
| Campos que nadie llena hace meses | Huérfanos de campañas muertas | Auditoría de uso y baja por etapas |
| La ficha exige scroll para lo básico | Sin carpetas ni priorización | Agrupación por carpetas y orden operativo |
| Un campo que guarda «historial» concatenado | Dato estructural forzado a casilla | Tabla externa con proyección del estado |
| Nadie sabe para qué existe un campo | Sin dueño ni propósito registrado | Inventario con responsable por campo |
Si reconociste tres o más filas, tu subcuenta ya está en la fase de acumulación. La buena noticia: se corrige sin drama, con el orden correcto.
¿Cuántos custom fields aguanta GoHighLevel de forma sana?
La plataforma soporta cientos de custom fields sin problema técnico; el límite sano es operativo: los que tu equipo puede nombrar, llenar y usar con propósito. En implementaciones reales, la degradación (duplicados, huérfanos, fichas ilegibles) aparece pasados los 40-60 campos sin gobernanza. Con convención de nombres, inventario con dueño y alta controlada, cien campos operan limpios.
Por qué los inventarios se degradan (y por qué no es culpa de nadie)
Cada campo nace de una necesidad legítima: la campaña que necesitaba «Fuente del lead», el formulario que pedía «Presupuesto estimado», la integración que escribía «Estado de pago». El problema es estructural: crear un campo cuesta diez segundos y no exige justificación, así que la fricción de crear es menor que la de buscar si ya existe. Multiplica eso por tres años, cuatro miembros del equipo y una docena de campañas, y el resultado es matemático. En el inventario de 133 campos que mencioné, el análisis de uso real arrojó el patrón típico: un tercio operativo de verdad, un tercio huérfano de campañas muertas, y un tercio duplicando información con nombres distintos, incluyendo cuatro versiones del presupuesto y tres del plan contratado.
El costo no es estético. Los duplicados rompen automatizaciones en silencio (el workflow ramifica sobre «Plan» mientras el formulario nuevo escribe en «plan_actual»: ambos ciertos, ninguno completo), los reportes mienten con confianza, y el equipo aprende a desconfiar de los datos, que es la muerte lenta de cualquier CRM. La normalización que documenté para webhooks ataca el mismo mal desde otro flanco: aquí lo atacamos desde el diseño del inventario.
Las tres reglas de gobernanza
1. Convención de nombres, desde antes del primer campo
Una convención mínima evita la mitad del desorden: prefijo de dominio + nombre descriptivo («fin_estado_pago», «mkt_fuente_lead», «op_plan_contratado»), un solo idioma, sin espacios creativos ni «v2». El prefijo agrupa visualmente, delata duplicados en el acto (dos «fin_» con nombres parecidos cantan solos) y hace que los merge tags de los workflows se lean como documentación. Las carpetas de campos de la plataforma complementan la convención agrupando la ficha por dominios: lo operativo arriba, lo analítico plegado abajo.
2. El inventario con dueño
Una hoja simple con cuatro columnas por campo: nombre, propósito, quién lo llena (humano, formulario, integración) y qué lo consume (workflows, reportes, nadie). Media hora de mantenimiento mensual, y dos superpoderes a cambio: la columna «qué lo consume» convierte cualquier limpieza futura de arqueología en checklist, y la fila nueva obliga a la pregunta que evita duplicados: «¿esto ya existe con otro nombre?». Es el mismo principio del catálogo con una sola fuente: los datos con dueño no divergen.
3. La frontera con la base externa
La regla que ya gobierna el reparto GoHighLevel/Supabase aplica campo a campo: el custom field es una CASILLA para el estado actual que el equipo ve y los workflows ramifican. En cuanto un dato pide historial («todos los pagos»), estructura («productos con variantes») o cálculo con reglas («estado derivado de transacciones»), forzarlo a casillas produce los engendros clásicos: el campo con JSON incrustado, el «historial» concatenado con comas, los cinco campos «pago_1» a «pago_5». La solución es siempre la misma: la tabla externa guarda la verdad completa y proyecta al campo solo la conclusión («al día», «atrasado»), que es lo único que la operación necesita ver en la ficha.
La limpieza de un inventario degradado, sin víctimas
El orden que funciona: primero el inventario completo con uso real (qué workflows, formularios y vistas tocan cada campo: esa dependencia es lo que hace peligroso el borrado alegre), después la fusión de duplicados (elegir el superviviente, migrar los datos del difunto vía API o exportación, redirigir los workflows, y solo entonces retirar), y al final los huérfanos por etapas: ocultar primero, esperar un ciclo completo de operación (un mes mínimo: hay campos que solo viven en la campaña trimestral), y retirar lo que nadie reclamó. El borrado masivo de sábado por la noche es el único método garantizado de descubrir el lunes qué automatización dependía de qué campo.
Errores comunes
- Crear sin buscar: el reflejo de «campo nuevo» sin revisar el inventario es la fuente número uno de duplicados. Diez segundos de búsqueda ahorran horas de fusión.
- Casillas numeradas: «intento_1», «intento_2», «intento_3» es una tabla pidiendo nacer. Al tercer campo numerado, la decisión ya está tomada aunque no la hayas tomado.
- Borrar sin mapa de dependencias: un campo retirado con workflows vivos apuntándole no avisa: simplemente las ramas dejan de cumplirse y nadie sabe por qué bajaron las conversiones.
- El campo multiusos: «Notas varias» acumulando datos que merecían campos propios (o una tabla). Lo que no se puede ramificar ni reportar, operativamente no existe.
- Gobernanza sin dueño: la convención que nadie custodia dura hasta la siguiente campaña urgente. El inventario necesita un responsable con nombre, no un acuerdo de buenas intenciones.
Preguntas frecuentes
Los límites publicados son lo bastante altos como para que el techo real sea siempre operativo: en la práctica, la degradación por desorden llega mucho antes que cualquier tope de plataforma. Diseña para tu equipo, no para el máximo del sistema.
La etiqueta marca pertenencia (está o no está: «webinar-enero», «cliente-vip»); el campo guarda un valor (cuál plan, cuánto presupuesto, qué fecha). El anti-patrón clásico es simular valores con familias de etiquetas («plan-basico», «plan-pro», «plan-premium»): eso es un campo de selección disfrazado, y ramifica peor.
Exportando o leyendo por API los valores del campo a retirar, escribiéndolos en el superviviente donde esté vacío (regla de precedencia explícita donde ambos tengan valor), redirigiendo formularios y workflows, y solo entonces retirando. La fusión es un mini proyecto de datos, no un clic.
El costo visible no es de máquina sino de humanos: fichas más lentas de leer, formularios internos más largos, más superficie de error en integraciones. Un inventario limpio es una optimización de operación diaria más que de servidor.
Con un multiplicador: el desorden clonado por snapshot se replica en cada cliente nuevo, y la limpieza pendiente se multiplica por N. La gobernanza en la subcuenta plantilla es la más rentable de todas: cada campo bien diseñado ahí nace bien en todas las cuentas futuras.
Criterios verificados auditando y gobernando inventarios reales de custom fields (el mayor, de 133 campos) en producción, a julio de 2026. Si tu subcuenta ya está en la fase de arqueología, esa auditoría y limpieza es un proyecto que hago.
La regla que resume todo
Un custom field es una promesa: alguien lo llenará, algo lo consumirá y significará una sola cosa. Los inventarios sanos no son los que tienen pocos campos, sino aquellos donde cada campo mantiene su promesa, y eso no lo garantiza la plataforma: lo garantiza la gobernanza de tres piezas (convención, inventario con dueño, frontera clara con la base externa). El CRM donde el equipo confía en los datos no es un accidente de disciplina personal: es un sistema donde crear un campo cuesta una decisión y romper una promesa cuesta una conversación. Monta ese sistema cuando tienes veinte campos, y nunca conocerás la arqueología de los 133.
