Qué es Make
Make es una plataforma visual de automatización e integración de aplicaciones. Su unidad de trabajo es el escenario: un conjunto de módulos que recibe datos, aplica operaciones y produce resultados. El catálogo actual anuncia más de 3.500 aplicaciones y la plataforma también incorpora agentes y asistencia de IA.
Una representación visual permite seguir el recorrido de la información, pero el comportamiento depende de los campos, condiciones y conexiones configurados. La pregunta principal es qué proceso se quiere resolver y qué evidencia permitirá comprobarlo. Un escenario sencillo puede tener más valor que un diagrama extenso si resuelve correctamente las excepciones y otra persona puede mantenerlo.
Documentación de referencia: About Make · Make scenarios documentation.
Historia: de Integromat a Make
Make procede de Integromat, una plataforma desarrollada en la República Checa. La biografía oficial de Patrik Simek, cofundador y CTO, sitúa el inicio de su proyecto en 2012; la página corporativa describe una trayectoria de servicio a clientes desde 2015. Son referencias a etapas diferentes de su desarrollo.
Celonis anunció la adquisición de Integromat el 14 de octubre de 2020. El 22 de febrero de 2022 se presentó Make como nueva marca y plataforma. Actualmente forma parte de Celonis y mantiene su sede en Praga.
La denominación anterior sigue apareciendo en tutoriales y escenarios antiguos. Al utilizar esos materiales, comprobar si describen el producto vigente, una interfaz anterior o condiciones comerciales que han cambiado. Tampoco deben atribuirse a Make las cifras de financiación o valoración de todo el grupo Celonis.
Documentación de referencia: Patrik Simek: co-founder and CTO · About Make · Celonis announces acquisition of Integromat · 2022 at Make: launch of the new brand and platform.
Módulos, paquetes de datos e iteradores
Make utiliza paquetes de datos, denominados bundles, para pasar información entre módulos. Un Iterator transforma una lista en paquetes separados; un Aggregator reúne varios paquetes en una salida conjunta. Entender esa diferencia ayuda a anticipar cuántas veces se ejecutarán los pasos posteriores.
Ejemplo editorial: una solicitud contiene tres referencias de materiales. Si se trata la lista como una unidad, puede generarse una sola tarea con tres referencias. Si se itera, pueden crearse tres tareas. Ambas opciones pueden ser correctas, pero responden a criterios de gestión distintos y requieren identificadores coherentes.
Antes de agrupar, decidir qué información debe conservarse de cada elemento. Un resumen que pierde el identificador del documento o su idioma puede resultar visualmente limpio y ser insuficiente para localizar la versión aprobada. Probar listas vacías, un único elemento y varios elementos repetidos.
Documentación de referencia: Iterator: arrays to bundles · Aggregator: bundles to a combined output.
Rutas, condiciones y reunificación
Router distribuye el flujo entre rutas y las procesa en secuencia, no en paralelo. Puede existir una ruta alternativa para datos que no cumplen las otras condiciones. If-else utiliza la primera condición verdadera y permite reunificar la ruta seleccionada mediante Merge. No son mecanismos intercambiables.
Para clasificar solicitudes por idioma, escribir las condiciones de forma explícita y reservar una salida de revisión para valores desconocidos. Evitar que una ausencia de información se interprete como aprobación o como elección automática de un idioma. La ruta alternativa debe tener responsable y resultado esperado.
Una prueba útil incluye condiciones que se solapan. Si una solicitud cumple dos reglas, comprobar qué debe ocurrir antes de implementar. El comportamiento deseado debe salir de la necesidad del proceso y después traducirse a la configuración del módulo adecuado.
Documentación de referencia: Router: routes and processing order · If-else and Merge.
Programación, webhooks y orden de ejecución
Un webhook recibe datos mediante una dirección HTTPS y puede iniciar un escenario al llegar una petición. Se diferencia de la consulta periódica de un servicio. Las ejecuciones de webhooks pueden procesarse en paralelo; la configuración permite exigir que una termine antes de iniciar la siguiente.
Esto es distinto del orden de las rutas dentro de una ejecución. Dos solicitudes simultáneas podrían intentar modificar el mismo registro aunque cada escenario tenga una secuencia interna clara. Para evitar conflictos, definir un identificador estable y una política para actualizaciones concurrentes.
Decidir también cuánto retraso es aceptable. Una cola administrativa puede esperar; una situación que requiere respuesta inmediata no debería depender de una automatización general sin un procedimiento alternativo. Medir el tiempo desde la recepción hasta el resultado, incluyendo espera, revisión y recuperación.
Documentación de referencia: Make webhooks · Scenario settings.
Entradas, salidas y componentes reutilizables
Las entradas y salidas de escenarios definen qué información recibe y devuelve una automatización. Permiten componer subescenarios y exponer funciones a otros sistemas, incluidos agentes. Los blueprints conservan módulos, configuración y valores mapeados para reutilizar o compartir el diseño.
Una pieza reutilizable necesita un contrato comprensible: campos requeridos, formatos, respuesta satisfactoria y respuesta de error. Por ejemplo, «localizar material aprobado» debería devolver una referencia y su versión, o indicar claramente que no existe una coincidencia válida. No conviene devolver un documento parecido como si fuera el solicitado.
Al reutilizar un diseño, revisar conexiones, permisos y datos de prueba. Copiar el esquema no demuestra que el nuevo entorno tenga los mismos campos ni que deba aplicar las mismas reglas. Conservar ejemplos de entrada y salida facilita el relevo entre personas.
Documentación de referencia: Scenario inputs and outputs · Scenario blueprints.
Make Grid y visibilidad del conjunto
Make Grid genera un mapa visual del entorno de automatización y sus relaciones. Su utilidad está en observar conexiones entre escenarios y aplicaciones, más allá de un único flujo. La presentación del producto explica una evolución desde una beta cerrada anunciada en 2024 hacia una beta abierta posterior.
Para aprovechar esa vista, distinguir dependencia técnica y dependencia operativa. Dos escenarios pueden compartir una aplicación, pero solo uno producir el dato que el otro necesita. Una revisión del mapa puede ayudar a localizar qué debe comprobarse antes de cambiar una conexión o retirar un recurso.
La documentación del equipo debería añadir propósito, propietario y criterio de aceptación. Esos elementos permiten interpretar el mapa y priorizar mantenimiento. La visibilidad técnica resulta más útil cuando se conecta con responsabilidades y resultados del proceso.
Documentación de referencia: Make Grid: visualising automation.
Maia y agentes de IA
Maia permite construir y modificar automatizaciones mediante conversación dentro del editor visual. La documentación también describe ayuda para comprender o depurar escenarios existentes. Make AI Agents incorpora ejecución de agentes y gestión de contexto; las opciones de proveedor y consumo varían según conexión y plan.
La asistencia al diseño y la ejecución autónoma cumplen funciones diferentes. Una propuesta generada puede acelerar el montaje, pero hay que revisar su lógica antes de activarla. Un agente que interpreta texto necesita límites sobre herramientas disponibles y sobre los cambios que puede realizar.
Para un piloto, elegir una tarea acotada, preparar ejemplos con respuesta conocida y registrar los casos ambiguos. Medir correcciones y tiempo de revisión junto al tiempo de construcción. Una salida convincente no sustituye una comparación con el resultado esperado ni demuestra que el proceso sea adecuado para información sensible.
Documentación de referencia: Maia: conversational construction and maintenance · Make AI Agents app.
Créditos, planes y estimación del coste
El 27 de agosto de 2025 los créditos sustituyeron a las operaciones como unidad de facturación. Una operación sigue describiendo actividad del escenario. Muchas funciones consumen un crédito por operación, pero algunas capacidades de IA tienen consumo variable; utilizar una conexión propia puede añadir facturación del proveedor de modelos.
La comparación entre planes debe incluir frecuencia de ejecución, volumen, funciones de equipo y soporte. No basta con dividir la cuota mensual por un número de escenarios. Una lista que se descompone en muchos elementos puede multiplicar el trabajo de módulos posteriores.
Para presupuestar, medir una muestra representativa y separar recepción, transformación, escritura y recuperación. Añadir casos sin coincidencia y repeticiones. El coste por caso correctamente resuelto ofrece una medida más útil que el coste de la primera prueba satisfactoria.
Documentación de referencia: Transition to credits on 27 August 2025 · Make credits and connection types · Make pricing and plan comparison.
Seguridad y datos en los registros
Make publica información sobre auditorías SOC 2 Type II y SOC 3, cifrado y controles de acceso. Su página de seguridad indica treinta días de conservación de logs por defecto y opciones adicionales para Enterprise. Son características del servicio que deben contrastarse con la modalidad contratada.
La opción de confidencialidad reduce la información conservada tras el procesamiento. La formación oficial advierte de que impedir guardar entradas y salidas también limita la posibilidad de almacenar y recuperar ejecuciones fallidas. Privacidad y diagnóstico deben resolverse conjuntamente, con una decisión explícita sobre qué evidencia conservar.
En un proceso documental, puede ser suficiente transportar referencias y estados sin copiar documentos completos. Definir quién puede consultar historiales, descargar diseños y modificar conexiones. Revisar los valores de ejemplo antes de compartir un blueprint, pues el diseño puede contener información que no estaba destinada a otros equipos.
Documentación de referencia: Security and compliance at Make · Incomplete executions and confidential data: Make Academy.
Aplicaciones auxiliares en SST
Como propuestas editoriales de Sabentis, Make puede servir para coordinar tareas repetitivas alrededor de la prevención, siempre que los conectores y permisos del entorno lo permitan:
- Preparar materiales: clasificar peticiones por idioma y referencia para que una persona seleccione la versión aprobada.
- Consolidar información: normalizar campos de varios registros antes de elaborar un informe, conservando origen y fecha.
- Coordinar revisiones: crear tareas internas a partir de un calendario de revisión documental, con responsable y referencia al documento.
Estas propuestas no atribuyen a Make un criterio técnico preventivo. Las reglas deben transportar decisiones ya definidas y dejar visibles los casos que requieren intervención humana.
Ejemplo hipotético: preparar una campaña en tres idiomas
Un equipo recibe solicitudes internas de fichas informativas en español, catalán e inglés. Quiere ordenar la preparación sin confundir una traducción disponible con un documento aprobado.
- Definir una entrada con identificador de solicitud, centro, idioma y código de material. Mantener fuera del proceso datos médicos y expedientes individuales.
- Validar los campos y encaminar cada solicitud a la cola de su idioma. Un idioma desconocido pasa a revisión, sin elegir otro automáticamente.
- Crear una tarea con la referencia de la versión aprobada y registrar su identificador en la solicitud original.
- Probar una interrupción entre la creación de la tarea y la actualización del origen. Antes de repetir, buscar la tarea existente para evitar duplicarla.
- Conciliar por idioma las solicitudes recibidas, las tareas creadas y las excepciones. Un responsable verifica la versión y decide su distribución.
La aceptación requiere que cada petición tenga un resultado identificable y que ninguna referencia apunte a un borrador. El número de módulos ejecutados no sustituye esta comprobación.
Ejecuciones incompletas y recuperación
Make permite almacenar ejecuciones incompletas, pero esta opción está desactivada por defecto. Una vez habilitada, los casos guardados pueden resolverse mediante reintentos admitidos o intervención manual. Su capacidad de almacenamiento depende del límite de uso.
Guardar un fallo no equivale a corregirlo. Asigna una persona a la cola de incidencias, define el plazo de revisión y establece qué acciones pueden repetirse sin crear duplicados. Comprueba también la caducidad de conexiones, los cambios de campos y el volumen esperado. Los datos retenidos para depurar pueden incluir información de entrada; minimízala y restringe el acceso.
Documentación de referencia: Incomplete executions.
Criterios para elegir Make
Resulta útil cuando interesa visualizar transformaciones y rutas y existe alguien que pueda mantenerlas. Antes de elegir, evalúa con un caso real la disponibilidad del conector, el coste por ejecución, la recuperación y la facilidad para que otra persona entienda el escenario.
Zapier permite comparar otra forma de conectar aplicaciones; n8n plantea opciones de despliegue que pueden ser relevantes cuando hay capacidad técnica propia. La elección debe incluir el mantenimiento posterior, no solo la rapidez del primer montaje.
Preguntas frecuentes sobre Make
¿Se guardan todos los errores automáticamente?
No debe suponerse. El almacenamiento de ejecuciones incompletas requiere activación y tiene límites. Comprueba la configuración de cada escenario.
¿Una ruta terminada significa que la tarea está resuelta?
Solo confirma lo que haya ejecutado esa ruta. Hay que verificar el registro creado, su contenido y la aceptación del resultado por quien corresponda.
¿Qué conviene documentar antes de entregar un escenario?
Entradas, salidas, identificadores, criterios de enrutamiento, conexiones, responsable y procedimiento de recuperación. Incluye ejemplos de datos válidos y casos rechazados.
Documentación de referencia: Incomplete executions.
