Un flujo fiable contempla el caso que falla
Una demostración suele usar datos completos y una conexión disponible. En trabajo cotidiano pueden faltar campos, repetirse registros o fallar una aplicación. Antes de activar un flujo, define cómo reconocer esos casos y qué información queda para revisarlos.
Un reintento puede resolver un fallo temporal, pero también repetir una acción que ya ocurrió. No basta con ejecutar de nuevo y esperar: debes saber si el resultado existe y qué identifica cada operación.
Una matriz de pruebas mínima
Caso completo: todos los campos correctos. Campo ausente: falta descripción. Campo inesperado: fecha con formato distinto. Duplicado: se recibe el mismo código. Fallo de conexión: el destino no responde en un entorno de prueba. Resultado ambiguo de IA: no se puede determinar una categoría con seguridad.
Para cada caso escribe resultado esperado, resultado observado y decisión. Puedes probar parte de la lógica en papel, pero antes de activar necesitarás verificar el comportamiento real del entorno y sus conectores.
Identifica una solicitud, no solo su texto
Utiliza un identificador estable, como PR-001 en datos ficticios. Antes de crear otra fila, define cómo comprobarás si ese identificador ya se procesó. Una consulta seguida de escritura puede necesitar controles adicionales si hay ejecuciones simultáneas; un prototipo pequeño no garantiza resolver concurrencia en producción.
No confundas una solicitud repetida con una nueva solicitud similar. El código debe representar lo que tu proceso considera una unidad y los cambios deben tener un tratamiento definido.
Práctica guiada
1. Procesa PR-001 y observa una única salida. 2. Vuelve a introducir PR-001 y comprueba qué ocurre. 3. Añade PR-002 sin descripción y revisa la salida alternativa. 4. Simula un destino no disponible sin afectar servicios reales. 5. Anota qué podrías repetir y qué necesita revisión manual.
La versión segura no pierde la solicitud incompleta ni crea dos acciones por el mismo evento. Si no puedes garantizarlo, mantén el prototipo en prueba y reduce su alcance.
Cuando hay IA en el flujo
Guarda el texto de entrada permitido y la propuesta de salida solo dentro del entorno autorizado. Valida los campos esperados. Si la respuesta contiene una categoría desconocida, un formato incorrecto o información ausente, deriva a revisión. No permitas que una respuesta en lenguaje natural controle cualquier acción externa.
Documentación para detener y mantener
Define propietario, conexiones, ubicación de registros y forma de desactivar. Mantén una copia de la configuración y una prueba después de cambios. No incluyas credenciales en esa documentación. Una automatización que nadie sabe detener todavía no está preparada.
Cursos para profundizar
Curso de Automatizaciones Básicas con Make (Platzi) incorpora manejo de errores en Make; Curso de Automatizaciones con n8n (Platzi) trata flujos de n8n con nivel intermedio y Crear y administrar procesos automatizados con Power Automate (Microsoft Learn) administración en Power Automate. Busca ejemplos que muestren fallos y revisión, no solo resultados exitosos.
Una matriz de prueba antes de activar el flujo
Ejemplo ficticio. Los tiempos son estimaciones editoriales de práctica, no tiempos medidos ni garantías de resultado.
| Caso | Entrada o situación | Comportamiento esperado |
|---|---|---|
| Normal | Código nuevo y campos completos | Una fila pendiente de revisión |
| Duplicado secuencial | Código ya registrado | Ninguna fila adicional; evento trazable |
| Campo ausente | Falta descripción | Registro de revisión con motivo |
| Solo espacios | Categoría sin texto útil | Se trata como campo vacío |
| Destino no disponible | La hoja de salida no responde | Error registrado; ningún mensaje externo anunciando éxito |
| Reintento tras guardado | El primer intento guardó y después falló | Se comprueba el código antes de volver a guardar |
| Dos ejecuciones simultáneas | Mismo código llega dos veces a la vez | La unicidad o el bloqueo evita dos filas; si no está implementado, el flujo no pasa esta prueba |
| Entrada corregida | Cambia descripción para un código existente | Sigue la regla declarada; no se inventa una actualización automática |
Registro mínimo de la prueba
Anota caso, resultado esperado, resultado observado, fecha de ensayo y corrección. No pongas claves, tokens o documentos personales en el registro. Si una prueba falla, reduce el alcance y vuelve a probar el caso después del cambio.
Señal de que todavía no está preparado
El flujo anuncia éxito aunque no se guardó nada, genera duplicados al reintentar o no explica qué ocurrió con una entrada incompleta. Resolver esos problemas forma parte del aprendizaje de automatización. Añadir IA no los corrige automáticamente.
Vuelve a los flujos de partida: primera automatización con Make y primer flujo de n8n.
Lección editorial con ejemplos ficticios. Los cursos recomendados se describen a partir de sus fichas públicas; no implica que los hayamos completado. Revisión inicial: 4 de octubre de 2026.