Hay un momento reconocible en la vida de toda cuenta de GoHighLevel madura: alguien cambia el precio de un plan, y el cambio hay que replicarlo a mano en once workflows, cuatro plantillas de email y dos funnels. Nadie recuerda si fueron todos. Tres semanas después, un cliente recibe una oferta con el precio viejo. El diagnóstico de fondo casi nunca se hace: el catálogo del negocio (productos, planes, precios, reglas) quedó incrustado en las automatizaciones, copiado en cada rama de cada árbol condicional, y cada copia es una oportunidad de divergencia.
Este artículo documenta el patrón que corrige eso: sacar el catálogo de los workflows y darle una sola casa, con las tres variantes según el tamaño del problema (custom values, campos calculados, base externa), los límites reales de los árboles condicionales de la plataforma, y el criterio para saber cuál te toca. Viene de sistemas en producción donde el catálogo se consulta, no se copia.
Respuesta rápida
- El problema: los if/else de los workflows terminan codificando el catálogo del negocio: cada precio, plan o regla copiado en decenas de ramas que hay que editar en paralelo.
- La regla: los workflows deciden el FLUJO (qué pasa y cuándo); el catálogo (qué vale, qué incluye, qué aplica) vive en un solo lugar consultable.
- Las tres casas posibles: custom values para catálogos chicos y estables; custom fields calculados por un proceso externo para reglas por contacto; base externa consultada por webhook/API cuando hay estructura real.
- La señal de alarma: si cambiar un precio implica tocar más de un lugar, el catálogo ya se te escapó a las automatizaciones.
| Tamaño del catálogo | Dónde vive | Cómo lo usan los workflows |
|---|---|---|
| Pocos valores estables (3 planes, 1 precio cada uno) | Custom values de la subcuenta | Referencia directa en mensajes y ramas |
| Reglas por contacto (qué plan tiene, qué le aplica) | Custom fields, calculados fuera | Ramas simples sobre el campo resuelto |
| Catálogo real (variantes, vigencias, combinaciones) | Base externa con API | Webhook consulta, recibe el valor resuelto |
Las tres variantes comparten el principio: una sola fuente, cero copias. Lo que cambia es la maquinaria que lo hace posible a cada escala.
¿Dónde debe vivir el catálogo de productos con GoHighLevel?
El catálogo (productos, planes, precios, reglas) debe vivir en un solo lugar consultable: custom values para catálogos pequeños y estables, custom fields calculados externamente para reglas por contacto, o una base externa cuando hay estructura real. Los workflows deciden el flujo y consultan el catálogo; nunca lo almacenan copiado en sus ramas.
Cómo se te escapa el catálogo a los workflows
Nadie lo decide: pasa por acumulación. El primer workflow menciona el precio del plan en un SMS («aprovecha el plan Pro a $149»). El segundo lo usa en una condición («si el campo plan es Pro, entonces…»). El tercero copia al segundo con un matiz. Un año después, el precio vive en catorce sitios, las reglas de qué incluye cada plan viven en los árboles de condiciones, y la lógica del negocio es arqueología: para saber qué pasa con un cliente Pro hay que leer workflows como quien excava. El costo no es estético. Es operativo (cada cambio de negocio es una expedición), es financiero (cada rama ejecutada suma, y las acciones premium se facturan), y es de riesgo: la copia número nueve que nadie actualizó es la oferta equivocada que sí se envió.
Los árboles condicionales de la plataforma tienen además un límite práctico antes que técnico: a partir de unas pocas ramas anidadas, el workflow se vuelve ilegible en el editor visual, imposible de probar rama por rama, y frágil ante el siguiente editor humano. El if/else visual es excelente para decidir flujo («¿respondió? ¿tiene cita?»); es pésimo como base de datos de reglas comerciales.
Las tres casas del catálogo, por escala
1. Custom values: el catálogo de bolsillo
Los custom values son variables de subcuenta: defines «precio_plan_pro» una vez y lo referencias en cada mensaje, email o funnel. Cambias el valor, cambia en todas partes. Es la solución completa para catálogos chicos y estables: tres planes, un precio por plan, un par de enlaces. Su límite es su naturaleza: son valores sueltos, sin estructura ni relaciones. Cuando empiezas a crear «precio_pro_anual_descuento_agencia», el nombre del custom value ya te está gritando que necesitas la siguiente casa.
2. Custom fields calculados: la regla resuelta por contacto
Cuando la pregunta no es «cuánto vale el plan Pro» sino «qué le aplica a ESTE contacto» (su plan, su descuento, su vigencia), el patrón correcto es el que documenté en el reparto GoHighLevel/Supabase: un proceso externo evalúa las reglas y escribe el resultado en un custom field («oferta_aplicable: renovacion_20»), y los workflows ramifican sobre ese campo resuelto con una condición simple. El árbol de siete niveles se convierte en una rama por resultado posible. Los workflows quedan legibles, las reglas quedan en código donde se prueban, y el catálogo tiene una sola pluma.
3. Base externa: el catálogo con estructura
Variantes, listas de precios por país, vigencias, bundles: eso es una tabla (o varias), no un conjunto de valores. El catálogo vive en una base externa, y los workflows lo consultan en el momento del flujo: el webhook sale con el ID del contacto y el contexto, el sistema resuelve contra el catálogo y responde (por inbound webhook o API) con el valor final que el workflow solo tiene que usar. GoHighLevel ejecuta; el catálogo decide. El requisito es tener la pieza externa (una base como Supabase y un endpoint), que es exactamente la arquitectura que ya justifican los pagos y la memoria de agentes si tu operación llegó a esa escala.
Cuándo NO aplicar el patrón
Si tu catálogo son tres valores que cambian una vez al año, los custom values te sobran y montar una base externa es arquitectura por deporte. La señal honesta para escalar de casa no es el entusiasmo técnico: es la frecuencia de cambios multiplicada por el número de lugares que hay que tocar. Tres valores en un lugar: quédate donde estás. Un cambio semanal en catorce lugares: ya llegaste tarde.
Errores comunes
- Precios escritos en el texto de los mensajes: la versión más común y más cara del problema. Todo precio en un mensaje debería ser una referencia a custom value, desde el día uno.
- El árbol que crece una rama por caso: cada caso nuevo del negocio añade un nivel al if/else. A la décima rama, nadie puede probar el workflow completo.
- Dos fuentes del mismo dato: el precio en un custom value Y escrito en dos funnels viejos. La migración a fuente única tiene que ser completa o la divergencia sigue, ahora con falsa confianza.
- Resolver reglas dentro del workflow que ya tienes resueltas fuera: si un sistema externo ya sabe el plan del contacto, ramificar de nuevo sobre datos crudos en el workflow duplica la lógica. Rama sobre el campo resuelto, siempre.
- Catálogo externo sin contrato de latencia: si el workflow espera la respuesta del catálogo, esa consulta debe responder en segundos o el flujo se degrada. El patrón de resolver ANTES (campo calculado) evita la espera en caliente.
Preguntas frecuentes
Los custom values son variables de la subcuenta (un valor global, como un precio o un enlace) reutilizables en mensajes, funnels y workflows. Los custom fields son datos por contacto. El catálogo general vive en values; lo que le aplica a cada cliente, en fields.
Tiene productos para cobros y facturación, y funcionan bien en ese papel. Lo que no modelan es el catálogo como fuente de reglas para automatizaciones (qué incluye cada plan, qué oferta aplica a quién): esa capa es la que este patrón resuelve.
Técnicamente más de las que deberías usar. El límite práctico es de mantenimiento: cuando el árbol no cabe legible en una pantalla del editor o no puedes probar cada rama en minutos, ya está grande. La solución no es otro workflow igual: es mover las reglas a una de las tres casas.
Para la primera casa (custom values), no: es configuración pura y puedes migrar esta semana. Las casas dos y tres requieren la pieza externa (un proceso que calcula, una base que responde), que es trabajo de implementación real o de quien lo haga por ti.
Con más razón: el catálogo embebido en workflows se multiplica por cada subcuenta clonada, y un cambio de precios del cliente se vuelve una expedición por N cuentas. Los custom values por subcuenta más snapshots bien diseñados mantienen el patrón replicable; el catálogo central externo lo escala del todo.
Patrón verificado en cuentas en producción donde el catálogo se consulta desde una sola fuente, a julio de 2026. Si tu operación ya tiene precios viviendo en catorce workflows, esa migración es un proyecto que hago.
La regla para llevarse
Los workflows son verbos; el catálogo es sustantivo. Los verbos deciden qué pasa y cuándo: si respondió, si pagó, si agendó. Los sustantivos (qué vale, qué incluye, a quién le aplica) merecen una sola casa con una sola pluma, del tamaño exacto del problema: un custom value, un campo resuelto o una base con API. Cada vez que un sustantivo se cuela en un verbo, el negocio queda escrito en un lugar donde no se puede leer, probar ni cambiar sin expedición. Sepáralos, y la pregunta «¿dónde está el precio?» vuelve a tener la única respuesta aceptable: en un solo sitio.
