Cómo probar un workflow antes de publicarlo a los clientes en GoHighLevel

Publicar un workflow sin haberlo probado antes es uno de los errores más habituales en GoHighLevel. Un paso mal configurado puede enviar correos duplicados, activar acciones en el momento equivocado o, peor aún, interrumpir una secuencia de ventas activa. Este tutorial explica cómo realizar pruebas controladas antes de que tus clientes o sus contactos reciban cualquier comunicación real.

Por qué es importante probar un workflow antes de activarlo

GoHighLevel ejecuta los workflows de forma automática en cuanto un contacto cumple la condición de entrada. Esto significa que, si publicas un workflow con errores, los efectos son inmediatos y pueden ser difíciles de revertir: mensajes enviados, etiquetas aplicadas o contactos movidos de pipeline sin quererlo.

Probar el workflow te permite:

• Verificar que cada rama condicional se evalúa correctamente.
• Confirmar que los tiempos de espera y los filtros funcionan como esperas.
• Detectar variables de personalización rotas (por ejemplo, {{contact.first_name}} que aparece en blanco).
• Asegurarte de que las integraciones externas (webhooks, Zapier, etc.) responden bien.

El proceso de prueba no elimina el riesgo al cien por cien, pero reduce considerablemente los errores en producción.

Métodos disponibles para probar un workflow en GoHighLevel

GoHighLevel no dispone de un entorno de staging separado del entorno de producción. Por eso, las pruebas se realizan dentro de la misma subcuenta, usando contactos y condiciones controladas.

1. Usar un contacto de prueba propio

Este es el método más directo y recomendable para la mayoría de workflows:

1. Accede a Contactos y crea un contacto nuevo con un correo y un número de teléfono que controles (por ejemplo, una dirección de prueba o un número secundario).
2. Ponle una etiqueta identificativa como test-interno para localizarlo fácilmente.
3. Ve a Automatización → Workflows y abre el workflow que quieres probar.
4. Asegúrate de que el workflow está en estado Borrador (no publicado) antes de continuar.
5. Haz clic en Agregar al workflow o usa la opción de entrada manual, según el trigger configurado.
6. Selecciona el contacto de prueba y confirma.
7. Observa el progreso en la pestaña Historial de ejecución del propio workflow.

2. Usar la función «Test Trigger» en el trigger de entrada

Algunos triggers, como los de formulario o de webhook, incluyen un botón Test Trigger o una opción de simulación dentro de su configuración. Cuando esté disponible:

1. Abre la configuración del trigger dentro del workflow.
2. Haz clic en Test Trigger (si el trigger lo soporta).
3. La plataforma simulará una entrada con datos de ejemplo y ejecutará los pasos siguientes.

Esta opción es útil para verificar que los datos del trigger llegan bien formateados, pero no siempre ejecuta todos los pasos del workflow. Comprueba manualmente los pasos posteriores si el trigger es complejo.

3. Revisar el historial de ejecución paso a paso

Una vez que el contacto de prueba ha entrado en el workflow:

1. Ve a Automatización → Workflows y abre el workflow.
2. Haz clic en la pestaña Historial o Ejecuciones (el nombre puede variar según la versión de la interfaz).
3. Localiza la ejecución del contacto de prueba.
4. Haz clic sobre ella para ver qué pasos se completaron, cuáles están en espera y si alguno generó un error.

Si un paso falla, la plataforma suele mostrar un mensaje de error junto al paso afectado. Esto es especialmente útil para diagnosticar problemas con acciones de envío de mensajes o condiciones if/else.

Buenas prácticas antes y durante la prueba

Antes de lanzar la prueba, revisa estos puntos:

• Desactiva o pon en modo prueba cualquier integración externa que no quieras activar de verdad (por ejemplo, webhooks que disparen acciones en un CRM externo).
• Revisa los tiempos de espera: si el workflow tiene pasos con esperas de horas o días, considera reducirlos temporalmente a 1 minuto para agilizar la prueba y vuélvelos a dejar en su valor original antes de publicar.
• Verifica las condiciones if/else: introduce datos en el contacto de prueba que cubran tanto la rama «Sí» como la rama «No» para asegurarte de que ambos caminos funcionan.
• Comprueba las variables de personalización: abre los correos o SMS enviados al contacto de prueba y confirma que los campos dinámicos se rellenan correctamente.
• Elimina o etiqueta las ejecuciones de prueba una vez terminadas, para no contaminar los datos de analítica del workflow.

Errores comunes al probar workflows y cómo resolverlos

El contacto de prueba no entra en el workflow Verifica que el trigger está configurado correctamente y que el contacto cumple todas las condiciones de entrada. Si usas entrada manual, comprueba que el workflow no tiene activado el filtro Permitir reentrada desactivado y el contacto ya pasó por él antes.

Los mensajes llegan vacíos o con variables sin rellenar Revisa que el contacto de prueba tiene los campos correspondientes rellenos (nombre, apellido, correo, etc.). Las variables como {{contact.first_name}} quedan en blanco si el campo está vacío en el perfil del contacto.

El workflow se detiene en un paso de espera y no avanza Si configuraste tiempos de espera largos para la prueba y olvidaste reducirlos, tendrás que editar el workflow, acortar el tiempo y volver a añadir el contacto. Recuerda que modificar un workflow mientras tiene contactos activos puede afectar esas ejecuciones en curso.

Las acciones de SMS o correo no se envían Comprueba que la subcuenta tiene configurado el canal correspondiente (número de teléfono verificado para SMS, dominio de correo configurado para email). Sin esa configuración, las acciones de envío fallan silenciosamente o generan error en el historial.

Los webhooks o integraciones externas disparan acciones reales durante la prueba Si tu workflow llama a un webhook de producción, esa llamada es real aunque el contacto sea de prueba. Usa una URL de webhook de prueba (por ejemplo, un endpoint de Webhook.site o un entorno sandbox de tu integración) mientras validas el workflow.

Cuándo este enfoque puede no ser suficiente

Si trabajas con workflows muy complejos que involucran múltiples subcuentas, lógica condicional profunda o integraciones de terceros críticas, las pruebas manuales dentro de GoHighLevel pueden quedarse cortas. En esos casos, considera:

• Documentar el flujo completo en un diagrama antes de construirlo.
• Hacer pruebas por fases, publicando el workflow solo hasta un determinado paso y añadiendo más pasos progresivamente.
• Revisar los logs de las integraciones externas de forma independiente.

GoHighLevel no ofrece actualmente un entorno de sandbox completo separado del entorno de producción. Si esto es un requisito crítico para tu caso de uso, es un factor a tener en cuenta a la hora de evaluar la plataforma.