Curso básico de Make y automatizaciones

Hasta ahora hemos visto qué es la automatización y qué herramientas existen. Pero puede que todavía tengas la duda:

👉 “Vale, pero ¿cómo funciona esto en la práctica? ¿Qué pinta tiene una automatización real?”

En esta ficha vamos a descubrir la estructura básica de cualquier automatización, sin entrar todavía en conceptos demasiado técnicos. La idea es que entiendas la lógica general, como si vieras el mapa de un viaje antes de caminarlo.

Cada automatización vive dentro de lo que se suele llamar escenario (en Make), zap (en Zapier) o workflow (flujo de trabajo, en general).

👉 Imagina que es el contenedor o caja donde sucede la magia. Dentro de ese escenario colocamos los pasos que queremos que se ejecuten.

💡 Ejemplo sencillo:

Un escenario podría ser: “Cada vez que alguien rellene un formulario (por ejemplo, con Google Forms), guarda su respuesta en una hoja de cálculo (por ejemplo, Google Sheets o Excel) y envíale un correo de confirmación (por ejemplo, con Gmail o Outlook).”

Dentro del escenario añadimos lo que las herramientas llaman módulos (en Make), pasos (en Zapier) o nodos (en n8n).

Un módulo es simplemente un bloque que realiza una tarea concreta dentro del flujo (escenario o workflow).

Podrías verlo como una cadena de montaje:

👉 De este modo, todos los módulos trabajan juntos como engranajes en un mecanismo.

La automatización, en el fondo, es un viaje de datos entre aplicaciones.

Lo bonito es que tú decides el camino: puede ser tan sencillo como un par de pasos, o mucho más complejo, con bifurcaciones y condiciones.

Pongamos un ejemplo clásico:

Google Forms (formulario online para recoger datos) → Make (herramienta de automatización) → Google Sheets (hoja de cálculo) → Gmail (correo electrónico).

👉 Todo esto sucede sin que tengas que hacerlo manualmente.

💡 Ejemplo de automatización sencilla realizada con Make que consiste en que cada vez que se alguien rellena un formulario (en este caso desde la aplicación Tally) se actualiza la Base de Datos de posibles clientes (Airtable) y envía un mail de bienvenida (Gmail) y se vuelve a actualizar la Base datos (Airtable) indicando que el mail ha sido enviado.

En esta ficha hemos aprendido que:

En la siguiente ficha veremos en detalle los componentes técnicos básicos de cualquier flujo:

Así, tendrás ya no solo el mapa, sino también las piezas clave que lo hacen funcionar.

En la ficha anterior vimos que una automatización vive dentro de un escenario y que está formada por módulos que ejecutan tareas. Pero, ¿cómo sabe Make cuándo empezar a ejecutar ese escenario? Aquí entra en juego el disparador (trigger).

👉 Un disparador o trigger es el evento inicial que activa el escenario. Sin disparador, la automatización nunca arranca.

Piensa en él como un “interruptor”.

◉ Algo ocurre → el disparador o trigger lo detecta → y eso pone en marcha todo el escenario.

◉ Sin disparador, el flujo o escenario está dormido.

Ejemplos con aplicaciones sencillas:

👉 En Make, el primer módulo del escenario siempre es el disparador. En esta ficha, más adelante se ve un dibujo aclaratorio.

Make ofrece dos grandes tipos de disparadores:

◉ Disparadores instantáneos (instant triggers): reaccionan al momento, tan pronto ocurre el evento.

◉ Ejemplo: un usuario envía un formulario desde Tally, el contenido de dicho formulario llega a Make y, el escenario arranca al instante. Aquí podemos observar el Trigger de Tally (pero podría ser de otras aplicaciones) en dónde el relámpago indica que el escenario se ejecutará de forma inmediata.

◉ Disparadores programados (scheduled triggers): Make revisa de forma periódica si hay algo nuevo o si debe ejecutar una tarea en un momento concreto.

👉 La frecuencia es totalmente configurable:

🔹 Cada pocos minutos (ej. cada 5, 10, 15, 30…).

🔹 Una vez al día, a la hora que tú decidas.

🔹 En días concretos de la semana (ej. solo lunes y jueves).

🔹 En días del mes o fechas específicas (ej. el día 1 de cada mes, el 31 de diciembre…).

🔹 etc…….

En la siguiente figura podemos ver un trigger o disparador para la aplicación de formularios Tally, que en lugar de ejecutar la automatización de forma inmediata (relámpago), lo hará en base al tiempo o días que lo hayamos configurado (reloj). Como se puede observar, en este caso no hay un relámpago, sinó un reloj.

Ejemplo: ejecutar un escenario cada día 1 a las 9:00 para generar y enviar un informe mensual en PDF. Esta diferencia es importante porque afecta a la rapidez de respuesta y también al consumo de operaciones (ya hablaremos de ello más adelante cuando empecemos a realizar automatizaciones de forma práctica).

4. 🖼️ Ejemplo visual con Tally + Airtable + Gmail

Imagina este escenario sencillo:

Tally (formulario) → Make (disparador al detectar respuesta nueva) → Airtable (guardar datos) → Gmail (enviar confirmació)

◉ Una persona rellena un formulario en Tally.

◉ El disparador en Make detecta la nueva respuesta.

◉ Los datos se guardan automáticamente en una tabla de Airtable.

◉ Se envía un correo de confirmación al usuario (o al administrador) a través de Gmail.

📌 Aquí el primer módulo (Tally) actúa como disparador.

5. 📝 Resumen de la ficha

Cuando añadimos un módulo en Make que corresponde a una aplicación externa (por ejemplo Gmail, Airtable o Telegram), Make necesita un permiso especial para poder trabajar con esa aplicación.

Ese permiso es lo que llamamos conexión.

👉 En otras palabras: una conexión es como darle una llave digital a Make para que pueda entrar en tu aplicación y automatizar tareas en tu nombre.

Ejemplo cotidiano: sería como darle a un amigo una copia de la llave de tu casa para que riegue las plantas. No le das tu casa, solo acceso limitado y revocable.

◉ Módulos internos de Make (por ejemplo: Formatter, Delay, Math) no necesitan conexión, porque no dependen de ninguna aplicación externa.

◉ Módulos de aplicaciones externas (por ejemplo: Gmail, Slack, Airtable, Telegram) sí requieren conexión. Antes de poder configurar el módulo, Make te pedirá crear o seleccionar una conexión.

Por ejemplo, la imagen superior muestra que cuando añades el módulo “Watch Records” de Airtable, lo primero que Make te pedirá es elegir/crear una Connection (Conexión). La imagen muestra exactamente ese campo “Connection” — es el primer paso que verás.

📌 Aclaración importante: esta imagen no enseña cómo crear la conexión completa; solo muestra que, para avanzar con un módulo de aplicación, debes tener una conexión. Si quieres ver el paso a paso para crear la conexión, consulta el Anexo: Conexión con Airtable (o el anexo correspondiente a la app que necesites).

Cada aplicación define su propio método de acceso; no eres tú quien decide el método, sino la aplicación (Make se adapta a lo que la app exige). Los métodos más habituales son:

4. ⚠️ Ojo con las diferencias (ejemplos prácticos)

5. 🧩 Ejemplo práctico (mini): crear una conexión sencilla

6. 📝 Resumen (punto rápido)

1. Un webhook es una forma de trigger en la que una aplicación externa avisa a Make en tiempo real cuando ocurre algo relevante.

2. Recordatorio (conectando con fichas anteriores): en la ficha 4 vimos los triggers: instantáneos (reaccionan en cuanto pasa algo) y programados/scheduled (Make mira cada X tiempo).

3. 👉 El webhook es otro tipo de trigger push : en vez de que Make vaya a preguntar, la aplicación externa empuja la información hacia Make.

4. Importante: no todos los triggers instantáneos son webhooks, y no todos los webhooks requieren que tú los programes manualmente. Algunas integraciones ofrecen triggers “instantáneos” ya preparados en Make (fácil para el usuario); otras aplicaciones requieren que tú configures un webhook explícito.

Ejemplo sencillo: es como si en lugar de bajar cada 10 minutos a preguntar si llegó el paquete, el repartidor tocase el timbre y avisara al instante.

◉ 📩 Entrante (incoming webhook): la app externa envía datos a una URL que crea Make → eso dispara el escenario.

◉ 📤 Saliente (outgoing webhook): Make envía datos hacia una URL externa (esto se hace con el módulo HTTP de Make).

💬¿Qué es eso de “llamada HTTP”?.

◉ ⚡ Usa triggers nativos de Make cuando existan y sean instantáneos (p. ej. algunos módulos oficiales como Tally, Stripe u otras integraciones que Make ya tiene). Son más simples: seleccionas el trigger y listo.

◉ 🔌 Usa un webhook cuando la app:

1. Añades en tu escenario el módulo Webhookmódulo Webhook (Custom webhook / Webhook response).

2. Make te genera una URL única (tu “timbre digital”).

3. Pegas esa URL en la app externa (o en su panel de webhooks), indicando cuándo debe enviar datos.

4. Haces una prueba (por ejemplo, envías un formulario) y verificas que Make recibe los datos.

Nota: no hace falta entender todos los tecnicismos ahora; el flujo general es “obtener URL → pegarla en la app que manda eventos → probar”.

◉ Ej. A (trigger nativo): Tally → Make con trigger oficial: el módulo instantáneo de Tally en Make recibe la respuesta al momento.

◉ Ej. B (webhook manual): Una plataforma sin integración oficial → Make → configuras un webhook en esa plataforma para que envíe datos a Make.

◉ Ej. C (pagos): Stripe → Stripe envía webhook a Make → Make guarda el pago en Airtable y manda confirmación por Telegram.

👉 Si hay un módulo de trigger oficial, úsalo; si no, pide al proveedor que envíe a la URL del webhook.

◉ 🔐 Usa siempre la URL tal cual Make te la da y no la compartas públicamente.

◉ 🔎 Muchas apps permiten firmar/identificar sus mensajes; cuando eso ocurra, lo veremos en un anexo avanzado

◉ 🧪 Para probar sin romper nada, haz siempre una prueba controlada (por ejemplo, envía un formulario de prueba).

◉ Un webhook es una forma de trigger push: la app externa avisa a Make al instante.

◉ Existen triggers instantáneos nativos y webhooks; ambos pueden dar inmediatez.

◉ Si Make tiene un trigger oficial, úsalo (es más cómodo). Si no, configura un webhook.

◉ Mantén la seguridad y prueba siempre con datos de test.

◉ Los detalles técnicos (JSON, firmas, idempotencia) van en un anexo para cuando quieras profundizar.

Una acción es lo que hace Make una vez que se dispara el escenario con un trigger (disparador).

👉 Piensa en esto como una reacción en cadena:

El timbre (trigger) no tiene sentido si después nadie abre la puerta (acción).

1. Alguien compra en tu tienda online → acción: Make envía un email de confirmación al cliente.

2. Recibes un formulario de contacto → acción: Make guarda la información en Airtable.

3. Te llega un pago en Stripe → acción: Make envía un mensaje a tu canal de Telegram avisando al equipo.

Cada una de estas tareas que ocurren después del “disparo” inicial es una acción.

◉ Trigger (disparador): Detecta un evento. Ejemplo: “Nuevo pedido recibido”.

◉ Acción: Hace algo con esa información. Ejemplo: “Crear un registro en Google Sheets con los datos del pedido”.

👉 Regla fácil de recordar:

◉ Trigger = aviso.

◉ Acción = reacción.

◉ Crear algo: Crear un registro en Airtable, un documento en Google Docs, un evento en Calendar.

◉ Enviar algo: Enviar un email, un mensaje de Slack, una notificación de Telegram, una notificación de Whatssap, etc.

◉ Actualizar algo: Cambiar el estado de un pedido en tu CRM, actualizar el stock en tu base de datos.

◉ Las acciones son las tareas que Make ejecuta después de un trigger.

◉ Siempre van de la mano: Trigger → Acción → Resultado.

◉ Ejemplo sencillo: “Cuando alguien llena un formulario (trigger) → guardar sus datos en una hoja (acción)”.

Hasta ahora, nuestras automatizaciones eran lineales: un trigger → una acción → un resultado.

Pero en la vida real, las cosas rara vez son tan simples.

Ejemplo cotidiano:

👉 Make también necesita esta capacidad de decidir qué hacer en cada caso.

Una ruta es como un desvío en la carretera dentro de tu escenario. El flujo puede seguir distintos caminos según lo que ocurra.

En Make, el módulo que permite crear estos desvíos se llama Router. Cada Router abre varios caminos posibles (llamados branches), y tú decides qué ocurre en cada uno.

Ejemplo:

👉 Piensa en el Router como una rotonda: llegas a un punto y eliges qué salida tomar según la información recibida.

Un filtro es como un semáforo: deja pasar la información solo si cumple una condición. Si no, la bloquea.

En Make, los filtros se aplican dentro de cada camino del Router o entre módulos, para controlar qué datos siguen adelante.

Ejemplo cotidiano:

◉ Solo dejas entrar a casa a personas que conoces → filtro = “¿conozco a esta persona?”.

◉ Solo respondes correos si contienen la palabra “urgente” → filtro aplicado en Make.

👉 Así, cada ruta del Router puede tener su propio filtro, garantizando que cada camino solo se use con la información adecuada.

La lógica es la capacidad de aplicar reglas más complejas dentro de un escenario.

Combina rutas + filtros + condiciones.

Ejemplo:

👉 Igual que tú no actúas siempre igual, Make puede reaccionar distinto según la situación.

◉ Rutas (Router) = desvíos del camino → distintos flujos según los datos.

◉ Filtros = semáforos → dejan pasar solo la información que cumple condiciones.

◉ Lógica = reglas de decisión que combinan rutas y filtros.

Con esto, tus escenarios dejan de ser lineales y se vuelven inteligentes y flexibles.

🔖 Nota importante

Todos estos ejemplos son introductorios para que entiendas la idea de rutas, filtros y lógica.

👉 Más adelante, haremos juntos escenarios prácticos en Make, donde verás paso a paso cómo aplicarlo en casos reales.

Un iterador en Make es como una herramienta que toma un “paquete” con varios elementos dentro y los va sacando uno a uno para que Make pueda trabajar con cada elemento por separado.

En muchos escenarios, los datos no llegan de uno en uno, sino en lotes:

Ejemplos:

Con un iterador, puedes procesar cada adjunto, cada respuesta o cada producto de manera individual.

Ejemplo de Make con Iterador (Iterator) que extrae los archivos adjuntos del mail y los copia en un carpeta de Dropbox

Piensa en una bandeja con tres galletas de chocolate.

Así puedes aplicar una acción a cada galleta por separado:

Escenario: recibes un pedido de una tienda online con 3 productos.

No te preocupes si al principio parece algo abstracto. Todos estos ejemplos y muchos más los practicaremos en escenarios reales, para que se entienda de forma visual y no se quede solo en la teoría.

El Array Aggregator de Make es un módulo que reúne varios elementos individuales en un único “grupo” (una lista o array) para que puedas procesarlos todos juntos después.

Sirve cuando no quieres procesar cada ítem o elemento de forma aislada, sino hacer algo con el conjunto: un informe diario, un email de resumen, un CSV con todas las entradas, un lote para enviar a otra API, etc.

Se adjunta ejemplo real creado con Make, el cual no os preocupéis porque lo veremos en detalle en los casos prácticos, en dónde se puede ver un escenario en dónde todos los archivos que se suben nuevos a una carpeta de Dropbox son enviados a un Array Aggregator, el cual los empaqueta en un único paquete para posteriormente enviar todos esos archivos en un único mail con el módulo de Gmail.

Ejemplo A — Digest de correos (resumen diario de leads)

Ejemplo B — Agrupar respuestas de un formulario

Ejemplo C — Resumen de productos de un pedido (optimizar llamadas a API)

🔔 Recuerda que el Array Aggregator trabaja con los datos recogidos en la ejecución del escenario. No acumula “en tiempo real” mientras llegan los elementos. Por eso, si quieres envíos periódicos (cada día, cada hora…), el control se configura en el trigger de tiempo, no en el agregador.

Imagina que estás organizando tus correos, respuestas de formularios o pedidos de productos: cada uno llega de manera individual, y tú quieres juntarlos todos en un mismo paquete para enviarlos o procesarlos de golpe.

💡 Analogía visual:

Piensa en el trigger como una fuente de objetos que cae sobre una cinta transportadora. El Array Aggregator es un cajón que los va recogiendo. Cuando Make decide pasar la caja al siguiente paso, todo lo que hay dentro viaja junto. La caja no tiene voluntad: solo recoge lo que le llega.

◉ Empieza con poco: prueba con 2–5 elementos antes de enviar grandes cantidades.

◉ Decide la frecuencia en el trigger: si quieres un digest diario, programa el trigger cada día; si quieres procesar todo al momento, programa disparos en tiempo real.

◉ Empieza con poco: prueba con 2–5 elementos antes de enviar grandes cantidades.

◉ Evita cajas gigantes: demasiados elementos juntos pueden ralentizar tu escenario o superar límites de Make.

◉ Mantén el orden si importa: los ítems llegan en el orden que los detecta el trigger; si el orden es importante, revisa que se mantenga.

◉ Evita duplicados: si hay riesgo de repetir elementos, añade lógica de filtrado antes de enviarlos al siguiente módulo.

◉ Registra para depuración: si los datos son importantes, guarda un registro temporal (por ejemplo, en Google Sheets) antes de enviarlos para poder revisar errores.

💡 Consejo de experto: el Array Aggregator es como un empaquetador pasivo: no decide nada, solo organiza. Todo el control de cuándo se ejecuta y qué llega lo determina el trigger y cómo configuras el escenario.

◉ Array Aggregator reúne múltiples ítems en una sola lista para procesarlos en bloque.

◉ Útil para digest, envío por lotes, crear CSV/resúmenes o reducir llamadas a APIs.

◉ Complementa al Iterator: uno divide, el otro junta.