Errores comunes en condiciones if/else dentro de workflows de GoHighLevel

Las condiciones if/else son uno de los elementos más potentes dentro de los workflows de GoHighLevel, pero también son una fuente habitual de fallos silenciosos que pueden arruinar automatizaciones enteras sin que el sistema muestre ningún error visible. En este artículo repasamos los problemas más frecuentes, por qué ocurren y cómo resolverlos de forma metódica.

Cómo funcionan las condiciones if/else en los workflows

Dentro del constructor de workflows, la acción If/Else permite dividir el flujo en dos ramas: la rama true (condición cumplida) y la rama false (condición no cumplida). El sistema evalúa la condición en el momento exacto en que el contacto llega a ese paso.

Cada condición se compone de tres partes:

1. Campo o variable que se quiere evaluar (por ejemplo, un campo personalizado, una etiqueta o el valor de una oportunidad).
2. Operador (igual a, contiene, está vacío, es mayor que, etc.).
3. Valor de referencia con el que se compara.

Cuando alguna de estas tres partes no está bien configurada, el contacto cae sistemáticamente en la rama false aunque intuitivamente «debería» pasar por la rama true. Ese es el síntoma más común de un error en la condición.

Errores más frecuentes y cómo corregirlos

1. Comparar texto con diferencias de mayúsculas o espacios

El operador Igual a es sensible al formato exacto del texto. Si el campo personalizado contiene "Madrid " (con un espacio al final) y la condición busca "Madrid", la comparación falla.

Solución: Utiliza el operador Contiene en lugar de Igual a cuando el valor puede incluir variaciones de formato. También revisa los formularios y fuentes de datos para estandarizar cómo se guardan los valores.

2. Evaluar un campo que todavía no tiene valor en ese momento del flujo

Es habitual colocar una condición if/else justo después del disparador, antes de que una acción previa haya tenido tiempo de escribir el valor en el campo. El resultado es que el campo está vacío y la condición siempre devuelve false.

Solución: Añade una acción de Esperar (Wait) o asegúrate de que la acción que rellena el campo se ejecuta antes de la condición. Revisa el orden de los pasos en el lienzo del workflow.

3. Confundir etiquetas con campos personalizados

Las etiquetas (tags) y los campos personalizados (custom fields) son entidades distintas. Un error muy común es intentar evaluar una etiqueta usando el operador de campo de texto, o viceversa.

Solución: En la condición if/else, selecciona correctamente la categoría. Para etiquetas, utiliza la opción Contact Tag y el operador Contains o Does Not Contain. Para campos personalizados, busca el campo en la sección correspondiente.

4. Usar variables de custom values en lugar de custom fields

GoHighLevel distingue entre Custom Values (valores globales de la cuenta) y Custom Fields (campos vinculados al contacto). Si introduces manualmente una variable como {{custom_values.nombre}} en el campo de valor de referencia, el sistema no la resuelve en la evaluación de la condición; la trata como texto literal.

Solución: Los valores de referencia en una condición if/else deben ser texto estático o, en ciertos operadores, campos del propio contacto. Si necesitas comparar con un valor dinámico, plantéate reestructurar el workflow o usar una acción de actualización de campo previa.

5. Condiciones múltiples con lógica AND/OR mal combinada

Cuando añades varias condiciones dentro de un mismo bloque if/else, el sistema permite combinarlas con lógica AND (todas deben cumplirse) o OR (basta con que se cumpla una). Un error frecuente es mezclar AND y OR sin ser consciente de la precedencia que aplica la plataforma, lo que produce resultados inesperados.

Solución: Si la lógica es compleja, divide el bloque en condiciones if/else anidadas en lugar de acumular muchas condiciones en un solo bloque. Esto hace el flujo más legible y más fácil de depurar.

6. Evaluar el estado de una oportunidad con el operador incorrecto

El campo de Pipeline Stage (etapa del pipeline) almacena un identificador interno, no el nombre visible en pantalla. Si escribes el nombre de la etapa tal como aparece en la interfaz, la condición no coincidirá.

Solución: Selecciona el campo Opportunity Stage desde el selector de campos de la condición y elige la etapa desde el desplegable correspondiente, en lugar de escribirla manualmente.

Cómo depurar una condición if/else paso a paso

1. Abre el workflow y localiza el bloque If/Else problemático.
2. Accede a la pestaña Execution Logs (o History, según la versión de tu plan) para ver en qué rama cayó el contacto de prueba.
3. Comprueba el valor real del campo en el perfil del contacto en el momento en que se ejecutó el paso.
4. Contrasta ese valor exacto con lo que has escrito en la condición, incluyendo mayúsculas, espacios y tipo de dato.
5. Si el valor del campo era correcto pero la condición falló, revisa el operador: prueba a cambiar Igual a por Contiene para descartar problemas de formato.
6. Guarda los cambios y usa la función Test Workflow con un contacto real o de prueba para validar el comportamiento.

Nota: El nivel de detalle disponible en los registros de ejecución puede variar según el plan contratado. En planes con funcionalidades limitadas, el historial puede mostrar menos información de diagnóstico.

Cuándo las condiciones if/else no son la mejor solución

Si tu workflow tiene más de cuatro o cinco niveles de condiciones anidadas, el mantenimiento se vuelve muy costoso. En ese caso, puede ser más eficiente:

• Dividir el workflow en varios workflows más pequeños y conectarlos mediante la acción Go To Workflow.
• Usar un campo de segmentación que se actualice antes del workflow y filtrar los contactos desde el disparador.
• Evaluar si la lógica realmente requiere un workflow o si podría resolverse con filtros de lista y acciones manuales.

GoHighLevel es una plataforma potente para automatizaciones de marketing y ventas, pero su constructor visual de workflows no está pensado para lógica condicional muy compleja. En escenarios avanzados, herramientas de automatización orientadas a desarrolladores pueden ser más adecuadas.

Buenas prácticas para evitar errores futuros

• Documenta cada condición añadiendo una nota descriptiva en el bloque (algunos planes permiten añadir comentarios al lienzo).
• Estandariza los valores de los campos personalizados desde el origen: formularios, integraciones o importaciones.
• Prueba con datos reales antes de activar el workflow en producción; los contactos de prueba sintéticos no siempre replican los valores reales.
• Revisa periódicamente los workflows activos cuando actualices campos personalizados o renombres etiquetas, ya que esos cambios no actualizan automáticamente las condiciones existentes.