El cambio número cincuenta no se parece al primero
Montar la automatización fue la parte fácil: no había nada que romper, nadie dependía de ella y el peor escenario era que no funcionase. Medio año después el escenario cambia de forma. El flujo lleva meses dando servicio, hay dos o tres personas que dependen de su salida sin saber siquiera que existe un flujo detrás, y alguien pide «un ajuste pequeño» en la lógica de asignación. El ajuste se toca en caliente un jueves por la tarde. El viernes por la mañana hay cuarenta correos que salieron al comercial equivocado y nadie sabe decir desde cuándo.
La diferencia entre los dos momentos no es técnica: es de riesgo. En del prototipo en Make a producción está el primer viaje, el de endurecer algo que funcionaba en la demo. Aquí va el viaje número cincuenta, que es el que se repite para siempre: cambiar algo que ya está vivo y da servicio, sin que la prueba se la coma el cliente.
La copia: datos de entrada reales, destinos de salida falsos
El error clásico es probar con datos inventados. Se crea un contacto de prueba llamado «Test Test», con un correo limpio, un teléfono con formato perfecto y un asunto de tres palabras, y la prueba pasa. Después llega la realidad: el nombre en mayúsculas con dos apellidos y un guion, el adjunto de once megas, el correo reenviado catorce veces con toda la conversación pegada debajo, el campo vacío que llevaba dos años sin estar vacío. Los datos inventados prueban que el flujo funciona con los casos que sí habías imaginado, que son exactamente los que nunca rompen.
La copia correcta se construye al revés: entra dato real, sale dato falso. Se duplica el flujo, se le mete el cambio, se le dejan intactas las credenciales de lectura y se le cambian todas las de escritura.
- Nombre que no engañe. La copia se llama con una convención estricta y visible —
[PRUEBA] nombre-del-flujo-fecha— para que nadie la confunda con la buena en un listado de cuarenta escenarios a las once de la noche. - Lectura real, escritura desviada. Cada paso que escribe fuera se redirige: el correo a un buzón interno, la fila del CRM a un objeto o una vista de pruebas, la notificación a un canal privado, el webhook saliente a un recolector que solo guarda lo que recibe.
- Cuidado con el disparador. Si la copia se dispara con el mismo evento que la original, el evento se procesa dos veces. O la copia se ejecuta a mano sobre una lista de casos guardados, o se le pone un filtro de entrada que solo deje pasar los casos de prueba.
- Casos guardados, no casos improvisados. Guarda diez o quince ejecuciones reales del último mes —las normales y las raras, incluida la que ya falló una vez— y pasa siempre las mismas por la copia. Eso convierte «me parece que va bien» en «estos quince casos dan lo mismo que antes salvo en lo que quería cambiar».
Las herramientas ayudan en la parte mecánica, pero ninguna te monta los destinos falsos: eso es trabajo tuyo y es donde se juega la seguridad de la prueba.
| Herramienta | Qué te da de fábrica | Qué tienes que montar tú |
|---|---|---|
| n8n | Fijar (pin) la salida de un nodo para reejecutar sin volver a llamar al origen; las ejecuciones de producción ignoran el dato fijado, así que no se cuela en la operación | Los destinos falsos: credenciales y variables de entorno propias de la copia apuntando a buzón, hoja y canal de pruebas |
| Make | Clonar el escenario y un historial de versiones desde el que restaurar una anterior | La copia clonada arrastra las mismas conexiones reales; hay que reapuntarlas a mano antes de la primera ejecución |
| Zapier | Borradores para editar un Zap sin apagarlo y una versión guardada cada vez que publicas, con vuelta atrás en los planes Professional, Team y Company | La publicación es total: la salida por porcentaje o por segmento no existe de fábrica, se monta con un filtro al principio del Zap |
Qué se puede probar en caliente y qué no: la línea la marca la escritura
Hay una única pregunta que decide si un paso se puede ejercitar sobre el flujo vivo: ¿deja rastro fuera? Si la respuesta es no, se puede probar en caliente sin daño. Si es sí, no se prueba en caliente nunca, y no hay versión moderada de esa regla.
- Se puede en caliente: leer, clasificar, extraer campos, puntuar, resumir, decidir una rama, calcular y escribir el resultado en un registro tuyo. El efecto se queda dentro y siempre puedes tirar el registro.
- No se puede en caliente: enviar correo, mensaje o factura a alguien de fuera; crear, actualizar o borrar en el CRM, el ERP o la base de datos de verdad; mover dinero; cerrar o reasignar un ticket que ve un cliente; publicar. El destinatario no distingue tu prueba de tu operación.
Entre las dos hay un caso intermedio que resuelve casi todo: la ejecución en seco. Dejas correr el flujo entero con datos reales y sustituyes el último paso —el que escribe fuera— por un registro que anota exactamente qué habría enviado, a quién y con qué contenido. Revisas ese registro con calma y tienes toda la información de una ejecución real sin ninguna de sus consecuencias. Es también la forma de descubrir el fallo que no da error: el correo que se habría enviado correctamente pero a la persona equivocada. Ese es el que la monitorización clásica no ve nunca, y está desarrollado en detectar fallos en automatizaciones.
Sacarlo por segmento y por porcentaje, no de golpe
Un cambio que ha pasado la copia todavía puede fallar en producción, y no porque lo hayas hecho mal: porque producción tiene casos que tu muestra no tenía. El volumen real, la hora punta, el cliente con la configuración rara, el mes de cierre. Publicar al cien por cien es apostar a que tus quince casos representaban el mundo. Casi nunca lo hacen.
- Primero por segmento, no por azar. El primer tramo tiene que ser el de menor coste si sale mal: solo peticiones internas, solo un equipo, solo un tipo de cliente, solo los casos de importe bajo. Un segmento es fácil de explicar, fácil de vigilar y fácil de revertir, porque sabes exactamente a quién llamar.
- Después por porcentaje, con reparto estable. Cuando el segmento aguanta, se abre a una parte del volumen general —diez por ciento, luego treinta, luego setenta—. El reparto se hace con algo estable del registro (los últimos dígitos del identificador, por ejemplo), nunca con un número aleatorio: si el reparto es aleatorio, el mismo pedido puede ir por la rama nueva hoy y por la vieja mañana, y entonces no puedes comparar nada ni explicar qué le pasó a un caso concreto.
- Al cien por cien solo cuando el tramo anterior ha sobrevivido a un ciclo entero. No a una tarde tranquila: a un ciclo completo del proceso, con su lunes por la mañana y su cierre de mes si el flujo los nota.
- El filtro sale del flujo cuando termina. Un reparto por porcentaje que se queda puesto seis meses es la próxima automatización zombi: media operación por una rama que ya nadie recuerda.
La ventana de observación: qué se mira y durante cuánto
«Lo vigilamos un rato» no es una ventana de observación. La ventana tiene que cubrir un ciclo completo del flujo: si el proceso tiene picos los lunes, hay que ver un lunes; si el volumen se concentra a fin de mes, hay que ver un fin de mes. Antes de abrirla necesitas la línea base —cuántas ejecuciones, cuántos errores y cuánto tardaba la semana pasada a la misma hora—, porque sin ella no estás observando: estás mirando.
| Qué se mira | Va bien si... | Se para si... |
|---|---|---|
| Volumen de ejecuciones | Se parece al de la semana pasada a la misma hora | Cae o se dispara sin motivo: el disparador cambió de comportamiento con el cambio |
| Tasa de error | Igual o menor que la línea base | Aparece cualquier error que no existía antes, aunque sea poco frecuente |
| Salida comparada | Las únicas diferencias son las que buscabas | Aparecen diferencias que nadie pidió: ahí hay un efecto lateral |
| Trabajo humano detrás | Nadie corrige a mano lo que sale del flujo | Alguien empieza a arreglar cosas «porque el sistema últimamente hace algo raro» |
La última fila es la más importante y la que casi nadie instrumenta. Los tres primeros indicadores los da la herramienta; el cuarto solo lo sabe la persona que recibe el trabajo. Por eso la ventana de observación incluye avisar a esa persona de que hay un cambio y pedirle explícitamente que diga si algo huele raro. Un cambio silencioso convierte a tu equipo en el sistema de detección, sin decírselo.
Vuelta atrás en cinco minutos: el ensayo, no el plan
Todo el mundo tiene plan de vuelta atrás. Casi nadie lo ha ejecutado nunca. Y un plan que no se ha ejecutado no es un plan: es una intención escrita en un documento que se abre por primera vez el día que todo va mal, que es justo el día en que nadie tiene cinco minutos.
- Guarda la versión buena antes de tocar nada. Con nombre y fecha, no «copia 3». Zapier crea una versión cada vez que publicas y permite volver atrás en los planes Professional, Team y Company; Make guarda historial de escenario para restaurar una versión anterior; en n8n lo limpio es exportar el flujo a JSON y versionarlo en el repositorio de la empresa, que además te da el diff que la interfaz no te da.
- Escribe quién puede revertir y por dónde se avisa. Una persona con permiso, un canal donde se anuncia, una frase. Si para revertir hay que localizar a la única persona que sabe, tu ventana de cinco minutos ya son dos horas.
- Ensáyalo una vez, con cronómetro. Sobre la copia: rompe algo a propósito y restaura. Si tardas quince minutos, no tienes una vuelta atrás de cinco: tienes un ejercicio pendiente.
- Ten claro qué no vuelve solo. Restaurar el flujo detiene la hemorragia, pero no des-envía los correos que ya salieron ni borra las filas que ya se crearon. Esa parte se limpia a mano y hay que saber de antemano cómo se localiza lo escrito en la ventana mala: por marca de tiempo, por etiqueta o por identificador de ejecución.
Ese último punto es el que separa el cambio ensayado del cambio valiente. La lista de lo que hay que limpiar se escribe antes de publicar, no después, y sale de la misma pregunta de antes: ¿qué escribe este flujo fuera? Cada escritura de esa lista necesita saber cómo se deshace. Si algo no se puede deshacer —un cobro, un correo a un cliente—, ese paso es justamente el que se saca el último y con el segmento más pequeño.
Nada de esto se sostiene si el flujo no está documentado: la copia, el reparto y la vuelta atrás dependen de que alguien sepa qué regla de negocio implementa cada rama, y eso está en documentar tus automatizaciones. Y cuando el cambio afecta a permisos, registros o auditoría, la pieza que falta es gobernanza y control de la automatización. El resto del mapa —qué automatizar y con qué criterio— vive en la guía madre de automatizar con IA.