Historial de ejecuciones y análisis de problemas
El historial de ejecuciones responde a la pregunta principal del control de la automatización: ¿se ejecutó la regla, el robot o el flujo de trabajo y, si no, por qué? Sin él no se sabe si la automatización realmente funciona o está parada en silencio. Esta página trata sobre cómo leer los resultados de las ejecuciones y analizar los problemas más habituales.
El historial está disponible en el mismo lugar donde vive cada motor: en las reglas de tarea está en la pestaña «Historial»; en los robots de CRM y los flujos de trabajo está en sus respectivas secciones.
Dónde ver el historial
- reglas de tarea — pestaña «Historial» en
/tasks/automation: registros de ejecuciones por tareas; - robots de CRM — historial de ejecuciones por oportunidades en la automatización de CRM;
- flujos de trabajo — historial de pasos en la ficha de la instancia y el resumen de «pasos pendientes de ejecutar»;
- pasos diferidos — resumen de la ejecución: cuántos se procesaron, con éxito y con error.
Empiece el análisis por el motor cuyo comportamiento le sorprendió y abra su historial para el objeto concreto.
Qué muestra un registro del historial
Cada registro del historial describe una ejecución:
- estado — cómo terminó la ejecución;
- hora — cuándo se ejecutó o se programó;
- objeto — la tarea u oportunidad sobre la que se ejecutó;
- motivo — código/explicación si la ejecución no se realizó;
- mensaje — texto sobre el error o el resultado.
La combinación «estado + motivo» es la herramienta principal del análisis: el estado dice qué ocurrió y el motivo por qué.
Resultados de la ejecución
La ejecución termina con uno de estos desenlaces:
- con éxito — la acción se realizó;
- omitido — la condición no se cumplió o la ejecución no estaba permitida, por lo que la acción no se aplicó;
- con error — la acción debía realizarse, pero no pudo;
- bloqueado — la operación fue detenida por una verificación de protección.
Omitido y bloqueado no son un fallo, sino un comportamiento normal según las reglas; el error es lo que requiere análisis.
Por qué una regla queda omitida
«Omitido» suele significar que la ejecución no encajó por condiciones o permisos:
- las condiciones de la regla no se cumplieron para este objeto;
- el alcance no incluye este proyecto, embudo o etapa;
- el responsable o la regla no tiene permisos para la acción necesaria.
Esto es normal: la regla deliberadamente no toca lo que está fuera de sus condiciones. Si debía ejecutarse, las condiciones o el alcance están demasiado restringidos o son incorrectos.
Por qué una ejecución queda bloqueada
«Bloqueado» significa que se activó una verificación de protección: la operación no pasó porque no se cumplió una condición obligatoria (por ejemplo, un campo sin rellenar antes de cambiar de etapa). No es un error de la automatización, sino un reglamento que se activó. Analícelo según el mensaje de la verificación: explica qué hay que rellenar o completar.
Por qué un paso terminó con error
«Con error» significa que la acción debía realizarse, pero no pudo. Causas frecuentes: el responsable de la acción no tiene permisos, falta un participante u objeto necesario, una configuración incorrecta de la acción, una operación externa no disponible (por ejemplo, enviar un correo sin una plantilla activa). Mire el mensaje del registro: indica la causa concreta.
Resultado parcial
En los robots y en las ejecuciones de «pasos pendientes de ejecutar» es posible un resultado parcial: una parte de la cadena o una parte de los pasos diferidos se ejecutó y otra no. En el robot depende de la política de error (detenerse o continuar); en la ejecución se ve en el resumen (procesado/con éxito/con error). El resultado parcial es más peligroso que un error completo: el objeto queda en un estado procesado a medias, por eso estos registros se analizan en primer lugar.
Correcciones habituales
- omitido cuando debía ejecutarse — revise las condiciones y el alcance;
- bloqueado — cumpla el requisito de la verificación de protección o ajuste la propia verificación;
- error de permisos — otorgue permisos al responsable de la acción o cambie de responsable;
- error al enviar el correo — compruebe que la plantilla esté activa y que las variables sean correctas;
- error repetido en el mismo paso — arregle la regla, el robot o la plantilla del flujo de trabajo, no el objeto a mano.
Buenas prácticas
- Revise el historial con regularidad, no solo cuando algo se rompe.
- Distinga el «omitido/bloqueado» normal del «error» real.
- Analice los resultados parciales en primer lugar.
- Corrija la causa en la configuración de la automatización, no la consecuencia a mano.
- Registre los errores repetidos como una señal para revisar la regla o el flujo de trabajo.
Errores frecuentes
Considerar «omitido» como una avería. Lo más habitual es que la regla deliberadamente no toque un objeto fuera de sus condiciones.
Arreglar el objeto a mano en lugar de la causa. El error se repetirá en la siguiente ejecución.
Ignorar el resultado parcial. El objeto queda en un estado inconsistente.
No leer el mensaje y el motivo. Indican directamente qué corregir.
Cómo comprobar que se ha arreglado
- una nueva ejecución (o una ejecución manual) termina con éxito;
- el registro del historial muestra el estado esperado sin errores;
- las ejecuciones bloqueadas desaparecieron tras cumplir el requisito de la verificación;
- los resultados parciales se llevaron hasta el final y el objeto está en un estado correcto;
- el error repetido ya no aparece en el historial.