Qué está pasando probablemente
Re-enrollment no está activado o no usa el trigger correcto
Un contacto que ya pasó por el workflow no vuelve a entrar solo porque siga cumpliendo la condición inicial. Debe volver a cumplir un trigger seleccionado para re-enrollment o ser enrolado manualmente bajo reglas compatibles.
El contacto sigue activo, fue suprimido o cumple una regla de salida
HubSpot no reinscribe un registro mientras sigue activo en el workflow. También puede saltarlo si está en suppression list, si cumple unenrollment triggers o si la configuración elimina contactos que dejan de cumplir condiciones.
El error fue de acción, no de enrollment
Una bandeja desconectada, un email en revisión, un contacto no marketing, una suscripción ausente, hard bounce, app rate limit, webhook timeout o objeto asociado inexistente puede hacer fallar una acción aunque la inscripción haya sido correcta.
Repetir desde el principio duplicaría efectos
Si el workflow crea tareas, actualiza lifecycle, asigna owner, crea deals, envía emails o activa otros workflows, re-enrolar todo puede ensuciar datos y métricas. A veces hace falta un workflow de rescate más pequeño.
Se perdió la ventana de historial o logs
HubSpot conserva action logs e historial durante ventanas limitadas. Si el análisis se hace tarde, puede faltar detalle para reconstruir exactamente qué paso falló.
La condición elegida no es válida para re-enrollment
No todos los triggers sirven para re-enrollment. Actividades, algunas propiedades calculadas, consentimientos o refinamientos por fecha/número pueden no comportarse como el equipo espera.
Cómo comprobarlo sin romper nada
Abre el workflow y revisa Issues, action logs y Enrollment history antes de tocar triggers o reenviar nada.
Elige 5 contactos afectados y comprueba para cada uno: entró o no entró, fecha, revisión del workflow, último paso alcanzado, error exacto y si completó o salió.
Comprueba si el workflow está activo, si el usuario tiene permisos de enroll, y si el contacto está actualmente activo dentro del workflow.
Revisa re-enrollment: toggle activado, triggers seleccionados, condición que debe cambiar y si el contacto realmente volvió de no cumplir a cumplir.
Mira suppression lists, unenrollment triggers, configuración de eliminar contactos que ya no cumplen criterios, y workflow goals si aplican.
Si falló un email, comprueba marketing contact status, email válido, hard bounce, subscription type, legal basis, graymail suppression y si el email estaba en revisión o bloqueado.
Si falló una acción de CRM, revisa objeto asociado, campos obligatorios, propiedad única, lifecycle stage hacia atrás, owner/team, permisos e integraciones conectadas.
Si falló un webhook o app externa, mira si HubSpot lo reintentará automáticamente, si hubo timeout, rate limit o respuesta 5xx, y si la acción externa pudo haberse ejecutado aunque HubSpot la marcara como fallida.
Exporta o crea una lista/segmento de contactos afectados antes de corregir, para no perder el grupo que necesita rescate.
Haz una prueba con un solo contacto antes de re-enrolar una lista grande. Si genera email/tarea/deal duplicado, detén el plan y crea un workflow de rescate.
Cómo lo resolvería paso a paso
Clasifica el fallo antes de re-enrolar
Etiqueta cada caso como no inscrito, acción fallida, email saltado, contacto suprimido, integración fallida o re-enrollment bloqueado. Esa clasificación decide la reparación.
Crea una lista de afectados con criterios verificables
No uses intuición. Construye una lista con contactos enrolados pero sin la acción final esperada: por ejemplo no enviados, sin tarea creada, sin propiedad actualizada o sin evento de integración.
Corrige la causa real
Reconecta inbox o app, cambia marketing contact status, arregla subscription/legal basis, corrige asociaciones, repara webhook, ajusta suppression lists o modifica triggers. Re-enrolar sin corregir solo repite el error.
Decide entre re-enrollment completo y workflow de rescate
Si el contacto debe repetir todo desde cero, usa re-enrollment/manual enrollment con una prueba previa. Si solo falta un tramo, clona o crea un workflow de rescate que empiece en el paso correcto y use una propiedad marcador.
Añade idempotencia operativa
Usa propiedades como last_workflow_rescue_date, email_x_sent, task_created o stage_updated para evitar doble envío y doble actualización. En automatización seria, cada acción sensible necesita una forma de saber si ya ocurrió.
Documenta el incidente
Guarda causa, contacto de prueba, lista afectada, decisión de rescate, fecha, workflow revision y resultado. La próxima vez no quieres volver a reconstruirlo desde cero.
Si se vuelve técnico
Puedes seguir esta ruta por tu cuenta. Si al comprobarlo aparece una discrepancia rara, una configuración de tracking delicada, una decisión de puja con riesgo o un bloqueo que requiere acceso a la cuenta, Lia guarda este contexto y te lleva a CreatikLab para continuar sin empezar desde cero.
Llevar este contexto a LiaQué no haría
Activar re-enrollment sin seleccionar triggers concretos.
Re-enrolar una lista grande sin probar un contacto.
Repetir un workflow completo cuando solo falló el último paso.
Ignorar suppression lists, unenrollment triggers o goals.
Confundir contacto no inscrito con contacto inscrito pero con acción fallida.
No revisar si el email fue saltado por non-marketing contact, hard bounce, suscripción o revisión de HubSpot.
Reenviar emails automáticos sin comprobar duplicados comerciales.
No crear una lista de afectados antes de marcar el issue como fixed o ignored.
Preguntas frecuentes
¿HubSpot reintenta automáticamente los contactos fallidos?
Depende del tipo de error. Algunos logs informativos, como ciertos timeouts, rate limits o fallos temporales de webhook, pueden reintentarse. Otros errores, como contacto no marketing, email bloqueado, suscripción ausente o objeto asociado inexistente, necesitan corrección y una estrategia de rescate.
¿Puedo re-enrolar manualmente una lista?
Sí, pero si los contactos ya pasaron por el workflow, HubSpot exige que re-enrollment esté activado de forma compatible. Además, el enrolamiento manual empieza desde el principio del workflow, así que puede duplicar acciones.
¿Qué hago si el error ocurrió en medio del workflow?
No repitas todo de entrada. Identifica el paso exacto, exporta afectados y decide si conviene un workflow de rescate desde ese punto. Es más limpio que volver a disparar emails y tareas anteriores.
¿Por qué un contacto que cumple criterios no vuelve a entrar?
Puede que re-enrollment esté desactivado, que el trigger no sea válido, que el contacto no haya cambiado de no cumplir a cumplir, que siga activo, que esté suprimido o que una regla de salida lo bloquee.
¿Cómo evito que esto vuelva a pasar?
Diseña workflows con propiedades marcador, ramas de éxito/error, listas de auditoría, notificaciones de issues, pruebas controladas y una convención clara para rescates. La automatización no debe depender de acordarse manualmente de quién falló.
