Fem feller i Make: scenarioer som ser riktige ut

Et scenario i Make.com har en ubehagelig egenskap: det kan se helt riktig ut og likevel levere feil.

Modulene står i rekkefølge. Ingen røde trekanter. Kjøringen fullfører grønt. Og det som kommer ut i den andre enden er tomt, halvt, eller subtilt forskjøvet på en måte ingen oppdager før noen spør «er du sikker på at dette tallet stemmer?».

Vi bygger automatisering for kunder, og vi bygger den i Make. Det som følger er fem feller vi har gått i selv, i produksjon, med tidsbruken det kostet. Ingen av dem står i noen kom-i-gang-guide. Fire av dem kostet oss timer før vi forsto hva vi så på. Den femte fant vi mens vi skrev denne artikkelen, ved å teste en påstand vi trodde vi visste svaret på.

Fellesnevneren er verdt å si først, fordi den er hele poenget: de fleste av disse feilene sier ikke fra. De kaster ingen feilmelding. De gir deg et grønt hakemerke og et galt resultat.

---

Kort vei til svaret: har du et scenario som kjører grønt og leverer feil, be oss se på det — vi finner som regel stedet. Vil du kjenne igjen mønstrene selv, les videre.

Slik vurderer vi fellene

Dette er ikke en gjennomgang av Make basert på dokumentasjon. Det er notater fra egne bygg, og hvert punkt nedenfor er noe vi har hatt hendene i.

Det vi kan stå inne for:

• Alle fem fellene er observert i våre egne scenarioer, ikke referert fra andre
• Der vi har en løsning som virker, står den beskrevet
• Der vi ikke vet hvorfor noe oppfører seg som det gjør, står det at vi ikke vet det
• Felle 5 ble testet på nytt 14. august 2026, med to kall vi kjørte mens artikkelen ble skrevet, og resultatene er gjengitt ordrett

Det vi ikke påstår: at dette er alle fellene, eller at de gjelder alle kontoer og alle versjoner. Make endrer seg. En funksjon som mangler i dag kan komme i morgen, og et prefiks kan bli et annet.

Derfor: denne artikkelen gjennomgås på nytt når Make endrer seg. Sist gjennomgått 14. august 2026. Ser du at noe har endret seg, vil vi gjerne vite det.

Skrevet av Svein Tore Olsen, daglig leder i Ebizapple, som holder til i Askim.

---

Felle 1: funksjonen finnes i JavaScript, men ikke i Make

Vi skulle formatere et tall til to sifre. Et ordrenummer, en måned, en teller — den slags som skal bli 07 og ikke 7.

I JavaScript er det én linje. padStart gjør nøyaktig dette, og har gjort det i årevis. Det er ikke en obskur funksjon; det er noe man skriver uten å tenke.

padStart finnes ikke i Makes funksjonsbibliotek.

Det er ikke en feil, og det er ikke udokumentert. Make har sitt eget sett av funksjoner, og det settet er ikke JavaScripts sett. Men det er en felle nettopp fordi den ikke ser ut som en felle: du skriver noe du har skrevet tusen ganger før, og verktøyet kjenner det ikke igjen.

Hva som skjer når du prøver

Du skriver uttrykket. Editoren tar det imot. Og resultatet blir ikke det du ba om — du sitter igjen med et uttrykk som ikke løses opp, eller en tom verdi der tallet skulle stått.

Det er den irriterende varianten: verktøyet stopper deg ikke, det bare gjør noe annet.

Løsningen: bygg strengen med vanlig sammensetning

Bygg strengen med vanlig sammensetning i stedet.

Prinsippet er enkelt: sjekk om verdien er kortere enn den skal være, og legg på nullene selv. To sifre betyr én test — er tallet under ti, sett en null foran. Tre sifre betyr to tester. Det er mindre elegant enn padStart, og det er fullstendig forutsigbart.

Den generelle lærdommen er større enn denne ene funksjonen: anta aldri at en JavaScript-funksjon finnes i Make fordi den er standard. Slå den opp i Makes eget funksjonsbibliotek før du bygger noe som avhenger av den. Det tar tretti sekunder, og alternativet er en halvtimes forvirring over hvorfor et helt trivielt uttrykk ikke virker.

---

Felle 2: feil prefiks gjør blueprinten umulig å importere

Denne kostet mest tid i forhold til hvor liten den er.

Vi skulle sette sammen tekst fra flere kjøringer — den klassiske jobben der en modul kjører mange ganger og du vil ha alt samlet i én streng til slutt. Det gjør en tekstaggregator.

Vi skrev builtin:TextAggregator i blueprinten.

Den heter util:TextAggregator.

Hvorfor det er verre enn en skrivefeil

En modul i en Make-blueprint identifiseres med to deler: et appprefiks og et modulnavn, skilt med kolon. Prefikset sier hvilken app modulen tilhører. Aggregatorer og hjelpefunksjoner ligger under util, ikke under builtin.

Feilen er på ett ord. Konsekvensen er at hele blueprinten ikke lar seg importere — Make finner ingen modul med det navnet, og avviser filen.

Det plagsomme er hvor riktig JSON-en ser ut mens du leser den. Alt er velformet. Klammene stemmer, feltene er der, strukturen er den samme som i et scenario som virker. Det eneste som er galt er en streng inne i et felt, og strengen ser fullstendig plausibel ut. builtin høres ut som stedet innebygde moduler bor.

Løsningen: kopier modulnavnet fra et scenario som virker

Kopier modulnavnet fra et scenario som allerede virker, i stedet for å skrive det fra hukommelsen. Eksporter en blueprint der modulen brukes, finn module-feltet, og lim inn nøyaktig den strengen.

Skal du bygge programmatisk, list modulene for appen først og les navnet derfra. Det er den eneste kilden som ikke kan huske feil.

---

Har du et scenario som ikke lar seg importere? Send oss blueprinten, så ser vi på den — det er som regel ett felt.

---

Felle 3: referansen som virker helt til scenarioet vokser

Denne er den verste sorten, og det er verdt å si hvorfor før vi sier hva den er.

Det finnes to slags feil. Den ene roper. Den andre tier og lar deg tro at alt er i orden. Denne tier.

I et scenario som tar imot inndata må du referere til den inndataen riktig. Vi skrev {{X}} — altså bare navnet på feltet.

Det skal være {{var.input.X}}.

Hvorfor du ikke oppdager det med en gang

I et scenario med én modul virker {{X}}. Det gjør det. Du bygger, du tester, det fungerer, du går videre.

Så legger du til modul nummer to. Og da slutter det å virke — men det sier ikke fra. Referansen løses ikke opp til noe. Den løses opp til ingenting. Modulen får en tom verdi, gjør jobben sin på den tomme verdien, og rapporterer suksess.

Kjøringen er grønn. Resultatet er tomt. Ingenting i grensesnittet peker på hva som skjedde.

Det er derfor denne fellen er dyrere enn de to første til sammen: du leter ikke etter en feil, for det står ingen feil noe sted. Du leter etter en logisk brist i noe som ser ut til å fungere.

Løsningen: bruk {{var.input.X}} fra første modul

Bruk {{var.input.X}} fra første modul, også når scenarioet bare har én. Kostnaden er null. Gevinsten er at scenarioet fortsatt virker den dagen noen utvider det.

Og legg til en vane: når et scenario går fra én til flere moduler, kjør en test som faktisk kontrollerer innholdet i svaret, ikke bare at kjøringen ble grønn. Grønn betyr «ingen modul kastet en feil». Det er noe annet enn «det kom riktig data ut».

Vi skriver mer om den forskjellen i artikkelen om hva vi gjør når to modeller er uenige — stille feil og uenighet er to sider av samme problem: du trenger noen som ser etter, fordi systemet ikke sier fra selv.

---

Felle 4: svaret som ser tomt ut hos den som spør

Et scenario kan brukes som et verktøy — noe et annet system, eller en AI-assistent, kaller og får et svar fra. Svaret sendes tilbake med en returmodul, og det ligger i et felt som heter tool_output.

ReturnData.tool_output må ha riktig type.

Får den feil type, skjer det ikke noe dramatisk. Det kastes ingen feil. Scenarioet kjører ferdig. Men hos den som kalte, ser svaret tomt ut.

Hvorfor det er så vanskelig å se

Fordi feilen ikke er der du leter. Du åpner kjøringen i Make og ser at modulen produserte data. Dataen er der, den er riktig, du kan lese den på skjermen. Så det må jo være mottakeren som er problemet.

Det er det ikke. Det er kontrakten mellom dere: scenarioets grensesnitt sier hvilken type tool_output har, og hvis den typen ikke stemmer med det du faktisk legger i feltet, kommer innholdet ikke gjennom i en form mottakeren kan lese.

I våre egne verktøyscenarioer er tool_output deklarert som en dynamicCollection. Det er ikke en type man gjetter seg til.

Løsningen: les typen fra et scenario som allerede virker

Les grensesnittet til et scenario som allerede virker som verktøy, og kopier typen derfra. Og test alltid fra utsiden — fra den som skal kalle scenarioet, ikke fra Makes egen kjør-knapp. Kjør-knappen viser deg hva modulen produserte. Den viser deg ikke hva mottakeren fikk.

Det er samme prinsipp som i enhver integrasjon: du har ikke testet en utlevering før du har stått på mottakersiden og sett på det som kom. Vi bruker den regelen på alt vi kobler sammen i automatiseringsprosjekter.

---

Felle 5: valideringen svarer på et annet spørsmål

De fire første fellene er gamle. Denne testet vi på nytt mens artikkelen ble skrevet, fordi vi ville vite hvor mye vi egentlig kan stole på verktøyene som sier «dette er gyldig».

Svaret var: mindre enn vi trodde, og på begge måter.

Test 1: den grønne løgnen

Vi laget en blueprint med to moduler. Den ene var builtin:TextAggregator — altså felle 2, med det gale prefikset. Den andre var denne:ModulenFinnesIkke, en modul vi fant på der og da og som ikke eksisterer i noen app.

Så sendte vi den gjennom skjemavalideringen.

Svaret var: «Blueprint is valid against the schema.»

Gyldig. En blueprint med én modul som har feil prefiks og én modul som ikke finnes i universet, er gyldig.

Det er ikke en bug. Skjemavalideringen kontrollerer strukturen — at feltene finnes, at typene stemmer, at JSON-en er formet som en blueprint skal være. Den slår ikke opp om modulnavnene eksisterer. Verktøyet sier det til og med selv, hvis man leser dokumentasjonen.

Men det er en felle, fordi den setningen leses av et menneske som akkurat har brukt en time på å bygge noe, og det mennesket leser «valid» som «dette kommer til å virke».

Det gjør det ikke. Blueprinten går rett i veggen ved import, med en melding om at modulen ikke ble funnet.

Test 2: den røde løgnen

Så gjorde vi det motsatte. Vi tok grensesnittet til et scenario som kjører i produksjon hos oss akkurat nå, og sendte det gjennom grensesnittvalideringen. Ikke et konstruert eksempel — det virkelige oppsettet, med inndata av typen url og utdata tool_output av typen dynamicCollection.

Svaret var valid: false, med tre innvendinger:

• Value 'url' not found in options.
• Value 'dynamicCollection' not found in options.
• Unknown field 'required'.

Altså: valideringen underkjente et oppsett som beviselig kjører. Typene den ikke kjente igjen, er typer scenarioet faktisk bruker. Og required — et felt som står i det live grensesnittet — ble avvist som ukjent.

Vi la også merke til en tredje ting på veien: et helt vanlig tekstfelt uten multiline blir avvist med «Field is mandatory». Ingenting i skjemaet antyder at et flagg om flerlinjet visning skulle være obligatorisk for at feltet skal godtas.

Hva fellen egentlig er

Fellen er ikke at valideringen er dårlig. Fellen er at ordene «valid» og «invalid» leses som en dom over om noe kommer til å virke, mens de i praksis er en dom over om noe passer inn i én bestemt liste.

Alle tre kolonnene til høyre er sanne. Det er kolonnen i midten som koster tid.

Løsningen: bruk valideringen til det den faktisk sjekker

Bruk valideringen til det den er: en billig sjekk av at du ikke har rotet til JSON-en. Ikke som et kvalitetsstempel.

Den eneste kontrollen som teller er at scenarioet lar seg opprette, at det kjører, og at noen ser på det som faktisk kom ut i den andre enden. Alt annet er indisier.

---

Tre til, i kortform

Grafikken øverst er klippet fra de samme notatene, og viser tre andre feller fra samme prosjekt. De hører hjemme i familien til de fem over: alle tre kjører uten feilmelding og leverer noe annet enn det du ba om.

• (?<cuid>) med feil hermetegn. Et navngitt fangstuttrykk skrevet med gale hermetegn rundt seg. Uttrykket så riktig ut i editoren og traff ingenting.
• Basic Aggregator ga {object}. Der vi ventet tekst, kom strukturen ut i stedet for innholdet.
• /[^A-Za-z ]/g spiser æ, ø og å. En tegnklasse som bare slipper gjennom A til Z, fjerner de norske bokstavene sammen med spesialtegnene. Resultatet er tekst som ser rensket ut helt til noen leser den.

Den siste er verdt å merke seg for alle som bygger noe på norsk. Et regulært uttrykk skrevet for engelsk tekst er ikke nøytralt — det er et uttrykk som er enig med engelsk og uenig med norsk.

---

Hvilken felle er det? En diagnosetabell

Tabellen er en sorteringshjelp, ikke en fasit. Den er bygget på symptomet du ser først, fordi det er der du står når noe ikke stemmer.

---

Skal dere sette opp automatisering som skal stå over tid? Vi bygger den, og vi dokumenterer hvor den kan knekke — ta en prat med oss om oppsettet.

---

Hva vi gjør annerledes nå

Fem feller gir fire vaner. De er kjedelige, og de er billige.

Vi kopierer modulnavn, vi skriver dem ikke. Fra en blueprint som virker, ikke fra hukommelsen. Dette ene punktet fjerner felle 2 helt.

Vi skriver {{var.input.X}} fra første modul. Også i scenarioer med én modul. Det koster ingenting nå og sparer en time senere.

Vi tester fra utsiden. Et verktøyscenario er ikke testet før noen har kalt det utenfra og lest svaret som kom tilbake. Kjør-knappen i Make forteller deg hva modulen produserte, ikke hva mottakeren fikk.

Vi behandler «grønn» som en påstand, ikke et bevis. En grønn kjøring betyr at ingen modul kastet en feil. Om det kom riktig data ut, er et separat spørsmål, og det må stilles separat.

Det siste punktet er egentlig det eneste som betyr noe. Alle de fem fellene har det til felles at systemet ikke sier fra. Da må noen se etter, og det må være noen som vet hva svaret skulle vært.

Det er den samme grunnholdningen som gjør at vi ikke lover en ytelsesscore vi ikke styrer, og som gjør at vi graderer hvor vanskelig en datakilde er før vi lover en dato. Å vite hva man ikke vet er en del av jobben.

---

Når Make er riktig verktøy — og når det ikke er det

En ærlig artikkel om feller må si noe om når verktøyet er verdt fellene.

Make er sterkt der jobben er å koble systemer sammen: hente noe fra ett sted, gjøre om på det, legge det et annet sted, og gjøre det igjen i morgen uten at noen trykker på noe. Det er lesbart for andre enn den som bygde det, og det gir deg en kjøringslogg du kan gå tilbake i.

Make er svakere der jobben er tung datamanipulasjon i mange ledd. Når et scenario blir en liten applikasjon med tjue moduler, nestede ruter og logikk bare én person forstår, har du bygget programvare i et verktøy som ikke er laget for å vedlikeholde programvare.

Skal dataene ut av en nettside som ikke vil gi dem fra seg, er det en egen øvelse — vi har skrevet om hva som møtte oss da vi hentet en hel produktkatalog. Skal resultatet vises fram som en filtrerbar oversikt, hører det hjemme under dynamiske nettsider, og skal det bo i et nettsted som skal vedlikeholdes, er det en WordPress-jobb like mye som en automatiseringsjobb.

---

Spørsmål om scenarioer i Make

Hvorfor finnes ikke padStart i Make?

Make har sitt eget funksjonsbibliotek, og det er ikke identisk med JavaScripts. padStart er ikke en del av det. Løsningen er å bygge strengen med vanlig sammensetning i stedet — sjekk lengden og legg på nullene selv.

Hva heter tekstaggregatoren i Make?

util:TextAggregator. Ikke builtin:TextAggregator. Bruker du feil prefiks, lar ikke blueprinten seg importere, selv om JSON-en er velformet og ser riktig ut.

Hvorfor gir scenarioet mitt tomt svar uten feilmelding?

To vanlige årsaker. Enten refererer du til inndata som {{X}} i stedet for {{var.input.X}} — det virker i scenarioer med én modul og slutter å virke uten varsel når du legger til flere. Eller så har ReturnData.tool_output feil type, slik at dataen finnes i Make, men ikke kommer gjennom til den som kalte.

Betyr «Blueprint is valid» at scenarioet vil virke?

Nei. Skjemavalideringen kontrollerer strukturen i JSON-en, ikke om modulene finnes. Vi sendte inn en blueprint med en modul vi fant på, og fikk «Blueprint is valid against the schema» i retur. Den samme blueprinten kan ikke opprettes.

Kan jeg la en AI-assistent bygge scenarioene for meg?

Delvis, og det er nyttig. Men alle fem fellene i denne artikkelen er av typen som ser riktig ut i JSON, og en assistent som ikke kjører scenarioet og leser resultatet, har ingen måte å oppdage dem på. Bygg gjerne med hjelp. Verifiser fra utsiden uansett.

Hvor lang tid tar det å finne en stille feil?

Vår erfaring er at det avhenger nesten helt av om du vet at kategorien finnes. Kjenner du mønsteret «grønn kjøring, tomt svar», er det minutter. Kjenner du det ikke, kan du bruke en ettermiddag på å lete etter en feilmelding som ikke finnes.

---

Videre lesing om automatisering

• Når to modeller er uenige — om å oppdage det systemet ikke sier fra om
• Automatisering av arbeidsprosesser — hva vi bygger, og hvordan vi overleverer det
• Vi prøvde å hente en hel produktkatalog — når kilden ikke vil gi fra seg dataene
• N1 til N5: hvor vanskelig er katalogen din? — anslå jobben før noen lover en dato
• Hvorfor vi ikke lover deg en score på 99 — om løfter man ikke styrer
• Én mal, ett datasett, én port — to scenarioer tegnet opp modul for modul
• Fem sider het «start her» — løsningen fantes, men lå to lag ned og ble bygget om igjen
• Dynamiske nettsider — når resultatet skal vises fram og filtreres
• WordPress-nettsider — nettstedet automatiseringen skal levere inn i
• Alle artikler i bloggen

Sitter dere med et scenario ingen tør røre, eller en automatisering som stoppet uten at noen vet hvorfor? Vi ser gjerne på det og sier ærlig hva som er verdt å rette — send oss en henvendelse.