Què és Make
Make és una plataforma visual d’automatització i integració d’aplicacions. La unitat de treball és l’escenari: un conjunt de mòduls que rep dades, aplica operacions i produeix resultats. El catàleg actual anuncia més de 3.500 aplicacions i la plataforma també incorpora agents i assistència d’IA.
Una representació visual permet seguir el recorregut de la informació, però el comportament depèn dels camps, condicions i connexions configurats. La pregunta principal és quin procés es vol resoldre i quina evidència permetrà comprovar-ho. Un escenari senzill pot tenir més valor que un diagrama extens si resol correctament les excepcions i una altra persona el pot mantenir.
Documentació de referència: About Make · Make scenarios documentation.
Història: d’Integromat a Make
Make prové d’Integromat, una plataforma desenvolupada a la República Txeca. La biografia oficial de Patrik Simek, cofundador i CTO, situa l’inici del seu projecte el 2012; la pàgina corporativa descriu una trajectòria de servei a clients des de 2015. Són referències a etapes diferents del desenvolupament.
Celonis va anunciar l’adquisició d’Integromat el 14 d’octubre de 2020. El 22 de febrer de 2022 es va presentar Make com a nova marca i plataforma. Actualment forma part de Celonis i manté la seu a Praga.
La denominació anterior continua apareixent en tutorials i escenaris antics. En utilitzar aquests materials, comprovar si descriuen el producte vigent, una interfície anterior o condicions comercials que han canviat. Tampoc s’han d’atribuir a Make les xifres de finançament o valoració de tot el grup Celonis.
Documentació de referència: Patrik Simek: co-founder and CTO · About Make · Celonis announces acquisition of Integromat · 2022 at Make: launch of the new brand and platform.
Mòduls, paquets de dades i iteradors
Make utilitza paquets de dades, anomenats bundles, per passar informació entre mòduls. Un Iterator transforma una llista en paquets separats; un Aggregator reuneix diversos paquets en una sortida conjunta. Entendre aquesta diferència ajuda a anticipar quantes vegades s’executaran els passos posteriors.
Exemple editorial: una sol·licitud conté tres referències de materials. Si es tracta la llista com una unitat, es pot generar una sola tasca amb tres referències. Si s’itera, es poden crear tres tasques. Totes dues opcions poden ser correctes, però responen a criteris de gestió diferents i requereixen identificadors coherents.
Abans d’agrupar, decidir quina informació s’ha de conservar de cada element. Un resum que perd l’identificador del document o l’idioma pot resultar visualment net i ser insuficient per localitzar la versió aprovada. Provar llistes buides, un únic element i diversos elements repetits.
Documentació de referència: Iterator: arrays to bundles · Aggregator: bundles to a combined output.
Rutes, condicions i reunificació
Router distribueix el flux entre rutes i les processa en seqüència, no en paral·lel. Pot existir una ruta alternativa per a dades que no compleixen les altres condicions. If-else utilitza la primera condició vertadera i permet reunificar la ruta seleccionada mitjançant Merge. No són mecanismes intercanviables.
Per classificar sol·licituds per idioma, escriure les condicions explícitament i reservar una sortida de revisió per a valors desconeguts. Evitar que una absència d’informació s’interpreti com a aprovació o com a tria automàtica d’un idioma. La ruta alternativa ha de tenir responsable i resultat esperat.
Una prova útil inclou condicions que se superposen. Si una sol·licitud compleix dues regles, comprovar què ha de passar abans d’implementar. El comportament desitjat ha de sortir de la necessitat del procés i després traduir-se a la configuració del mòdul adequat.
Documentació de referència: Router: routes and processing order · If-else and Merge.
Programació, webhooks i ordre d’execució
Un webhook rep dades mitjançant una adreça HTTPS i pot iniciar un escenari quan arriba una petició. Es diferencia de la consulta periòdica d’un servei. Les execucions de webhooks es poden processar en paral·lel; la configuració permet exigir que una acabi abans d’iniciar la següent.
Això és diferent de l’ordre de les rutes dins d’una execució. Dues sol·licituds simultànies podrien intentar modificar el mateix registre encara que cada escenari tingui una seqüència interna clara. Per evitar conflictes, definir un identificador estable i una política d’actualitzacions concurrents.
Decidir també quin retard és acceptable. Una cua administrativa pot esperar; una situació que requereix resposta immediata no hauria de dependre d’una automatització general sense procediment alternatiu. Mesurar el temps des de la recepció fins al resultat, incloent espera, revisió i recuperació.
Documentació de referència: Make webhooks · Scenario settings.
Entrades, sortides i components reutilitzables
Les entrades i sortides d’escenaris defineixen quina informació rep i retorna una automatització. Permeten compondre subescenaris i exposar funcions a altres sistemes, inclosos agents. Els blueprints conserven mòduls, configuració i valors mapats per reutilitzar o compartir el disseny.
Una peça reutilitzable necessita un contracte comprensible: camps requerits, formats, resposta satisfactòria i resposta d’error. Per exemple, «localitzar material aprovat» hauria de retornar una referència i la versió, o indicar clarament que no hi ha una coincidència vàlida. No convé retornar un document semblant com si fos el sol·licitat.
En reutilitzar un disseny, revisar connexions, permisos i dades de prova. Copiar l’esquema no demostra que el nou entorn tingui els mateixos camps ni que hagi d’aplicar les mateixes regles. Conservar exemples d’entrada i sortida facilita el relleu entre persones.
Documentació de referència: Scenario inputs and outputs · Scenario blueprints.
Make Grid i visibilitat del conjunt
Make Grid genera un mapa visual de l’entorn d’automatització i les seves relacions. La utilitat és observar connexions entre escenaris i aplicacions, més enllà d’un únic flux. La presentació del producte explica una evolució des d’una beta tancada anunciada el 2024 cap a una beta oberta posterior.
Per aprofitar aquesta vista, distingir dependència tècnica i dependència operativa. Dos escenaris poden compartir una aplicació, però només un produir la dada que l’altre necessita. Una revisió del mapa pot ajudar a localitzar què cal comprovar abans de canviar una connexió o retirar un recurs.
La documentació de l’equip hauria d’afegir propòsit, propietari i criteri d’acceptació. Aquests elements permeten interpretar el mapa i prioritzar manteniment. La visibilitat tècnica és més útil quan es connecta amb responsabilitats i resultats del procés.
Documentació de referència: Make Grid: visualising automation.
Maia i agents d’IA
Maia permet construir i modificar automatitzacions mitjançant conversa dins de l’editor visual. La documentació també descriu ajuda per comprendre o depurar escenaris existents. Make AI Agents incorpora execució d’agents i gestió de context; les opcions de proveïdor i consum varien segons connexió i pla.
L’assistència al disseny i l’execució autònoma compleixen funcions diferents. Una proposta generada pot accelerar el muntatge, però cal revisar-ne la lògica abans d’activar-la. Un agent que interpreta text necessita límits sobre eines disponibles i sobre els canvis que pot fer.
Per a un pilot, triar una tasca acotada, preparar exemples amb resposta coneguda i registrar els casos ambigus. Mesurar correccions i temps de revisió juntament amb el temps de construcció. Una sortida convincent no substitueix la comparació amb el resultat esperat ni demostra que el procés sigui adequat per a informació sensible.
Documentació de referència: Maia: conversational construction and maintenance · Make AI Agents app.
Crèdits, plans i estimació del cost
El 27 d’agost de 2025 els crèdits van substituir les operacions com a unitat de facturació. Una operació continua descrivint activitat de l’escenari. Moltes funcions consumeixen un crèdit per operació, però algunes capacitats d’IA tenen consum variable; utilitzar una connexió pròpia pot afegir facturació del proveïdor de models.
La comparació entre plans ha d’incloure freqüència d’execució, volum, funcions d’equip i suport. No n’hi ha prou amb dividir la quota mensual per un nombre d’escenaris. Una llista que es descompon en molts elements pot multiplicar el treball dels mòduls posteriors.
Per pressupostar, mesurar una mostra representativa i separar recepció, transformació, escriptura i recuperació. Afegir casos sense coincidència i repeticions. El cost per cas correctament resolt ofereix una mesura més útil que el cost de la primera prova satisfactòria.
Documentació de referència: Transition to credits on 27 August 2025 · Make credits and connection types · Make pricing and plan comparison.
Seguretat i dades als registres
Make publica informació sobre auditories SOC 2 Type II i SOC 3, xifratge i controls d’accés. La pàgina de seguretat indica trenta dies de conservació de logs per defecte i opcions addicionals per a Enterprise. Són característiques del servei que s’han de contrastar amb la modalitat contractada.
L’opció de confidencialitat redueix la informació conservada després del processament. La formació oficial adverteix que impedir guardar entrades i sortides també limita la possibilitat d’emmagatzemar i recuperar execucions fallides. Privacitat i diagnòstic s’han de resoldre conjuntament, amb una decisió explícita sobre quina evidència conservar.
En un procés documental, pot ser suficient transportar referències i estats sense copiar documents complets. Definir qui pot consultar historials, descarregar dissenys i modificar connexions. Revisar els valors d’exemple abans de compartir un blueprint, ja que el disseny pot contenir informació que no estava destinada a altres equips.
Documentació de referència: Security and compliance at Make · Incomplete executions and confidential data: Make Academy.
Aplicacions auxiliars en SST
Com a propostes editorials de Sabentis, Make pot coordinar tasques repetitives al voltant de la prevenció, si els connectors i permisos de l’entorn ho permeten:
- Preparar materials: classificar peticions per idioma i referència perquè una persona seleccioni la versió aprovada.
- Consolidar informació: normalitzar camps de diversos registres abans d’elaborar un informe, conservant origen i data.
- Coordinar revisions: crear tasques internes a partir d’un calendari de revisió documental, amb responsable i referència al document.
Aquestes propostes no atribueixen a Make criteri tècnic preventiu. Les regles han de traslladar decisions ja definides i fer visibles els casos que requereixen intervenció humana.
Exemple hipotètic: preparar una campanya en tres idiomes
Un equip rep peticions internes de fitxes informatives en castellà, català i anglès. Vol ordenar-ne la preparació sense confondre una traducció disponible amb un document aprovat.
- Definir una entrada amb identificador de sol·licitud, centre, idioma i codi del material. Deixar fora del procés dades mèdiques i expedients individuals.
- Validar els camps i dirigir cada petició a la cua del seu idioma. Un idioma desconegut passa a revisió, sense triar-ne un altre automàticament.
- Crear una tasca amb la referència de la versió aprovada i registrar-ne l’identificador a la sol·licitud original.
- Provar una interrupció entre la creació de la tasca i l’actualització de l’origen. Abans de repetir, cercar la tasca existent per evitar duplicar-la.
- Conciliar per idioma les peticions rebudes, les tasques creades i les excepcions. Un responsable verifica la versió i en decideix la distribució.
L’acceptació requereix que cada petició tingui un resultat identificable i que cap referència apunti a un esborrany. El nombre de mòduls executats no substitueix aquesta comprovació.
Execucions incompletes i recuperació
Make permet emmagatzemar execucions incompletes, però l’opció està desactivada per defecte. Un cop habilitada, els casos desats es poden resoldre amb els reintents admesos o amb intervenció manual. La capacitat d’emmagatzematge depèn del límit d’ús.
Desar un error no equival a corregir-lo. Assigna una persona a la cua d’incidències, defineix un termini de revisió i estableix quines accions es poden repetir sense duplicats. Comprova també la caducitat de connexions, els canvis de camps i el volum previst. Les dades retingudes per depurar poden incloure informació d’entrada; minimitza-la i restringeix-ne l’accés.
Documentació de referència: Incomplete executions.
Criteris per triar Make
És útil quan interessa visualitzar transformacions i rutes i hi ha algú que les pugui mantenir. Abans de triar, avalua amb un cas real la disponibilitat del connector, el cost per execució, la recuperació i la facilitat perquè una altra persona entengui l’escenari.
Zapier permet comparar una altra manera de connectar aplicacions; n8n ofereix opcions de desplegament que poden ser rellevants quan es disposa de capacitat tècnica pròpia. La decisió ha d’incloure el manteniment posterior, no només la rapidesa del primer muntatge.
Preguntes freqüents sobre Make
Es desen tots els errors automàticament?
No s’ha de donar per fet. Desar execucions incompletes requereix activar l’opció i té límits. Comprova la configuració de cada escenari.
Una ruta acabada significa que la tasca està resolta?
Només confirma allò que hagi executat aquesta ruta. Cal verificar el registre creat, el contingut i l’acceptació del resultat per qui correspongui.
Què convé documentar abans de lliurar un escenari?
Entrades, sortides, identificadors, criteris d’encaminament, connexions, responsable i procediment de recuperació. Inclou exemples de dades vàlides i casos rebutjats.
Documentació de referència: Incomplete executions.
