Debugging y límites
Logs de ejecución
Logs en la barra superior del builder lista cada ejecución: fecha, estado (Éxito, Falló, Saltado), registro que la disparó, nodos ejecutados y duración. Al expandir una, ves cada paso: el nodo, qué hizo (la rama que tomó una condición, el valor que asignó, la request y la respuesta de una integración con su tiempo), el estado de las variables después del paso y, si falló, en cuál y con qué mensaje.
Para un error intermitente, filtrá por Falló y mirá las variables justo antes del paso que falló: casi siempre señala el campo vacío o la condición mal escrita.
Orden real al guardar un registro
- Las antes corren antes de la validación: lo que completan ya se valida. Si una falla o cancela, no se guarda nada y el usuario ve el mensaje.
- Las después corren con el registro ya guardado: si fallan, el registro queda igual y el error solo aparece en los logs. Si un error tiene que impedir el guardado, va en una antes.
- Varias automations sobre el mismo evento corren en el orden de ejecución que definís en la configuración de cada una; en antes, los cambios de una pasan a la siguiente.
- Un registro creado o actualizado por una automation dispara sus propias automations, hasta 5 niveles de encadenamiento.
Detalle completo: Qué pasa al guardar un registro.
Contexto de ejecución (Run as)
En Configuración del builder elegís con qué identidad corre el flujo:
| Modo | Quién “hace” las acciones |
|---|---|
| Usuario que disparó (default) | Quien guardó el registro. Sus permisos y su sharing limitan lo que el flujo ve y escribe; queda como creador de lo que crea |
| Usuario específico | Un usuario fijo (una cuenta de servicio). Si está inactivo, cae al anterior |
| Sistema | Sin restricciones de permisos ni sharing. Lo que crea queda sin creador |
Para ejecutar una integración o un componente, la identidad efectiva necesita el permiso correspondiente en su permission set.
Validación al guardar el flujo
Nodos sin conectar, referencias a nodos o variables inexistentes, configuraciones incompletas (un Enviar email sin template) → error al guardar. Un flujo inválido no se puede activar.
Límites
| Límite | Valor |
|---|---|
| Tiempo máximo por ejecución | 10 segundos (después, Flow execution timeout) |
| Nodos por flujo | 50 |
| Pasos por ejecución (cada pasada por un nodo cuenta, loops incluidos) | 500 |
| Consultas Obtener registro por ejecución | 20 |
| Registros por Obtener registro en modo lista | 200 |
| Iteraciones por loop | 100 |
| Encadenamiento de automations | 5 niveles |
| Automations por workspace y ejecuciones por día | Según el plan (Plan y uso) |
Errores comunes
| Mensaje / síntoma | Causa y solución |
|---|---|
record.id vacío | En antes de crear el registro todavía no tiene id. Mové la lógica a después de crear |
| Variable X not found | No está declarada en Variables o tiene un error de tipeo |
| Loop exceeded max iterations | La lista supera 100. Filtrá más en el Obtener registro o procesá en tandas |
| Email template not found | El template se borró o cambió de slug. Reconfigurá el nodo |
| Flow exceeded 500 execution steps | Probable loop infinito o loop con demasiados nodos adentro |
| Input validation failed (endpoint) | El cuerpo de la llamada no cumple el esquema de entrada: tipos o campos faltantes |
| Una después no aparece en los logs | ¿Está Activa? ¿La operación coincide (crear vs. actualizar)? ¿Las condiciones de entrada la descartan? ¿Corre con un usuario sin acceso al registro? |
| 202 / éxito en el webhook pero “no pasó nada” | Un nodo recibió un dato con el tipo equivocado (un objeto como texto) y salteó en silencio. Revisá el esquema de entrada: un campo JSON tiene que declararse como objeto / lista, no texto |
Rendimiento
- Filtrá en Obtener registro, no con condiciones después.
- Evitá Obtener registro dentro de loops: traé todo una vez e iterá.
- Lo que no necesita correr antes del guardado, va en después: no bloquea al usuario.
- Las integraciones y los componentes tienen latencia: agrupá llamadas.