Y tú, ¿cómo lo harías?

Mira que me gusta complicarme la vida a veces… o no.

Ayer me encontre con un dilema automatista del que me apetecía hablarte, que siempre me gusta ver otros puntos de vista.

Uno de mis clientes me pidió repetir EXACTAMENTE la misma automatización que ya teníamos montada, cambiando un pequeño detalle.

En concreto, era esta automatización que ya lleva meses funcionando sin fallo y que utilizamos en el proceso de onboarding de cada uno de sus clientes:

Obviamente él no me habló de la automatización, sino del problema a resolver:

— Ahora que ya tenemos funcionando el formulario de inicio de proyecto para los clientes de XXXX (uno de sus servicios) necesito uno igual para el servicio de ZZZZZ. Lo único que cambia es el paso final, pero a ti eso no te afecta, es cosa del formulario.

Como ves arriba, es un proceso que se dispara al rellenar un formulario (en este caso, de Tally.so) y ahora había que repetir lo mismo pero con un formulario diferente.

Mismos campos y mismo proceso, solo cambiaba el trigger (porque Make no permite 2 triggers en la misma automatización).

¿Solución? Fácil. Copiar escenario, pegar escenario, cobrar automatización al cliente… y ¡a otra cosa, automatista!

¿O no?

Ya sabes aquello de «si algo funciona, ¿para qué tocarlo?». Pero claro, la newsletter se acabaría aquí, esto sería muy corto… y a mí me gusta jugar (y pensar) a largo plazo.

Si lo que vendo es que seamos más eficientes NO PUEDO permitir hacer automatizaciones que no sean eficientes. Y este proceso de duplicar una automatización idéntica… NO es eficiente. Ni sostenible. Ni fácilmente mantenible.

Así que le di una vuelta con algo que me gusta mucho ejecutar

Escenarios encadenados en Make: automatizaciones que llaman a automatizaciones

Podría venirme la tara de mi pasado programador, pero el principio es el siguiente: si un proceso se repite debes extraerlo, parametrizarlo y convertirlo en una función que llamas siempre que necesites.

¿Y cómo se traduce esto a Make? Haciendo automatizaciones que llamen a otras automatizaciones.

Hasta hace no mucho, esto siempre lo había hecho a través de un webhook y una petición API. Pero gracias a un chivatazo de Manuel Algara (gran automatista, mejor persona 😉) me enseñó un cambio que había aplicado Make a los módulos de su propia aplicación.

Sí, por si no lo sabías una de las herramientas que tienes disponibles para conectar a Make… es tu propio Make. Y uno de los módulos que tiene disponibles es «Run a scenario», que no deja mucho a la imaginación: te permite ejecutar cualquier escenario para el que tengas permiso.

Así que el proceso que seguí fue el siguiente:

  • Me llevé el 90% de la lógica de la automatización inicial a otro escenario
  • Definí toda la lista de parámetros de entrada que tenía ese escenario (las respuestas que venían del formulario).
  • Simplifiqué la automatización al escenario que ves arriba. Una automatización de dos pasos que se encarga de:
    • Leer la respuesta del formulario
    • Ejecutar el escenario (la función) que se encarga de procesarlo.
  • Ahora sí pude duplicar ese nuevo escenario y cambiar el trigger por el del nuevo formulario que necesitaba el cliente.

¿Y qué has ganado con esto, Santy? Porque ahora:

  • En lugar de 2 escenarios, tienes 3.
  • En cada ejecución consumes mínimo una operación extra de Make.
  • Has tardado bastante más en montarlo.

¿Tiene sentido hacerlo así?

Para mi yo de hoy, seguramente no. Para mi yo del futuro… rotundamente sí:

  • Si mañana cambia la definición de alguna pregunta, lo toco en un sitio y no en dos.
  • Si mañana cambia el proceso y necesitamos nuevos pasos, lo toco en un sitio y no en dos.
  • Si mañana no trabajamos con Tally sino con Typeform, lo toco en un sitio y no en dos.
  • Lo mismo con Asana, con Google Docs o con cualquiera de los procesos.
  • O si mañana son 4 formularios en lugar de dos.

En definitiva: la solución es mucho más eficiente pensando en próximos cambios o en el mantenimiento del proceso. Podría decirse que son principios de la Programación Orientada a Objetos (la forma más eficiente de programar) aplicados a la automatización de procesos.

No se puede negar el pasado 😂😂😂.

Y cierro con la misma pregunta que empezaba: y tú, ¿cómo lo habrías hecho? Porque me apetece mucho leerte 👀👀👀

Por cierto: antes del domingo quiero terminar de cerrar las fechas de la nueva edición del Desafío Automatista, que empezará en unas semanas. Si quieres que te mantenga al tanto… dale clic para enterarte antes que nadie.

Saludos 🫡
Santy.

PD: una de las sesiones en directo del Desafío la voy a dedicar a «trucos» de estos. Y las plazas van a ser bastante limitadas, ya sabes.

¿Tu primera vez por aquí?

Cada jueves envío un e-mail con un consejo accionable para mejorar tu relación con el tiempo y que puedas dedicárselo a lo que realmente importa.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acepto la política de privacidad *

Resumen de privacidad

Como la mayoría de sitios web, utilizamos cookies propias y de terceros para fines analíticos y para mostrarte publicidad personalizada o a partir de tus hábitos de navegación.
Por lo general, la información no lo identifica directamente, pero puede proporcionarte una experiencia web más personalizada. Ya que respetamos tu derecho a la privacidad, puedes escoger no permitirnos usar ciertas cookies. Sin embargo, el bloqueo de algunos tipos de cookies puede afectar tu experiencia en el sitio y los servicios que podemos ofrecer.
Para más información, puedes leer nuestra política de cookies.

Cookies analíticas

Estas cookies nos permiten contar las visitas y fuentes de circulación para poder medir y mejorar el desempeño de nuestro sitio. Nos ayudan a saber qué páginas son las más o menos populares, y ver cuántas personas visitan el sitio. Toda la información que recogen estas cookies es agregada y, por lo tanto, anónima.