Rescato una idea de la que te hablé hace un par de semanas.
Si quieres ser mejor en algo hay 2 técnicas que están 100% probadas:
- Hacer cosas, hacerlas más veces y retarse para subir el nivel.
- Juntarse a gente que sabe para aprender de ellos.
Que esto aplica a aprender inglés, ajedrez, esgrima antiguo, punto de cruz… o automatizar, claro.
Te enseño un par de automatizaciones, a ver qué te parecen:
¿Y si te dijera que hacen exactamente lo mismo?
Bueno, salta a la vista que lo mismo lo mismo… no. Pero resuelven el mismo problema.
En concreto se encargan de procesar las altas de nuevos alumnos en una academia de danza. Es un cliente con el que llevo años trabajando y del que he hablado bastante por aquí.
Y aunque estábamos construyendo cosas muy chulas y potentes (como el escenario de arriba), hace unos meses en una reunión en la que estábamos comentando nuevos procesos para automatizar en el curso que arranca en septiembre, le propuse hacer una migración total.
Corte del sistema. Borrón y cuenta nueva.
Tomar todo lo que hemos aprendido estos años y construir un nuevo sistema más robusto y escalable, que nos permita reducir errores y tener mucho más control sobre el proceso.
Aprovechamos, además, para migrar el núcleo del sistema desde Google Sheets a Airtable y empezar a construir mucho desde ahí.
Y en toda esa migración, y unida a las novedades de Make de los agentes IA que te comentaba la semana pasada, aparece un módulo que me tiene enamorado.
Run a subscenario
Yo siempre he sido muy fan de partir escenarios en piezas pequeñas que se llaman entre sí.
Hasta hace no mucho utilizaba lo que podía:
- El escenario «hijo» arrancaba con un webhook al que mandaba parámetros.
- El escenario «padre» hacía una petición HTTP, como si fuera una API, para enviarle esos datos.
El año pasado empecé a usar la API de Make para simplificar el proceso usando el «Run a scenario»… aunque aún tenía fallitos que no me gustaban.
Ahora ha surgido algo mucho más avanzado. Es un módulo nativo que nos permite desde un escenario ejecutar cualquier otro escenario que tengamos en nuestra cuenta de Make, siempre que esté configurado para que el trigger sea «On demand» (es decir, no es ni un trigger instantáneo ni de los que configuras por fecha).
Y que aporta muchísimas ventajas:
- Te permite definir la entradas (inputs) que debe recibir el escenario, marcando además el formato, si son obligatorios, etc.
- Lo mismo con los argumentos de salida (outputs).
- Desde el escenario padre haces la llamada y puedes marcar que espere la respuesta del hijo.
- Además, te devuelve automáticamente las variables de salida del escenario, para que puedas mapear los módulos siguientes.
- Esto lo descubrí hace poco → al ejecutarse el subescenario, el módulo en el que defines la salida no consume operaciones. Y como tampoco necesitas arrancar con un webhook ahora, me ahorro otra operación más (que son baratas, sí. Pero quitarse 2 de un plumazo está bastante bien).
Y no, no necesitas usar IA ni agentes ni nada para poder utilizar este módulo. Como ves, yo lo estoy utilizando para optimizar mucho mis flujos «normales».
Aquí, por ejemplo, tengo montada una cadena de subprocesos:
- El escenario principal procesa una solicitud de alta.
- Llama al secundario para tramitar el alta del alumno en Stripe
- Y a su vez, llama a otro escenario secundario para tramitar el alta en WordPress.
Porque tanto la funcionalidad de «buscar/crear» cliente o usuario de WordPress es algo que usamos mucho en otras piezas del puzzle. Y sacándolo en pequeños escenarios nos permite optimizar y agilizar la implementación.
¿Conocías el módulo de «run a subscenario»? ¿Lo has utilizado?
Te leo 👀👀👀👀
Santy.
PD: seguramente grabe un vídeo o dos sobre este tema para el curso de trucos para Make.
PD2: sí, es posible que te flipe mucho más el escenario que tiene 30 pelotitas y tropecientas ramas… pero a mí me daba urticaria cada vez que lo tenía que tocar. Palabra de automatista 🥲