Sådan bygger I en automatisering, der tåler at køre to gange
Sådan beskriver I et flow, håndterer gentagne kald og undgår samtidige dubletter med en nøgle i modtagersystemet. Med konkrete kontrolpunkter.
Den samme oplysning bliver tastet ind to steder, fordi kalenderen og CRM'et ikke taler sammen. Det er den slags dobbeltarbejde, en automatisering kan fjerne. Men i samme øjeblik en maskine overtager tastningen, skal I beslutte, hvad der sker, når det samme trin kører to gange. Et flow kan prøve igen, når nettet falder ud, og en kollega trykker send en ekstra gang, når kvitteringen udebliver. Begge dele er normal drift, ikke uheld.
Skriv arbejdsgangen ned, før I bygger
Start med én arbejdsgang, I kan beskrive fra ende til anden. Skriv den, som I ville forklare den til en kollega. Det er også den form, vi beder om, når nogen sender os en ide: på ide-siden beder vi netop om, at I skriver, som I ville forklare det til en kollega, og at fagsprog og kravspecifikation ikke er nødvendigt. For hvert trin noterer I tre ting: hvad der kommer ind, hvad trinnet skriver, og hvem der ejer det, hvis trinnet fejler.
Et eksempel: en forespørgsel kommer ind på mail. Flowet læser navn, telefonnummer og hvad sagen drejer sig om, opretter en sag i CRM'et, sender en kvittering til kunden og lægger en opgave ind, hvis der ikke er svaret efter et par dage. Det er den slags systemer, vi binder sammen: økonomisystem, kalender, mail og telefoni, der taler sammen.
Så kommer undtagelserne, og de er selve arbejdet. Mailen uden telefonnummer. Svaret i en gammel tråd, som ikke er en ny sag. Reklamen, der ligner en forespørgsel. Skriv ned, hvad der skal ske med hver af dem. Vores anbefaling er en synlig kø frem for en stille kassering: det, flowet ikke kan afgøre, skal kunne ses af et menneske samme dag.
Gentagelser skal have samme tilsigtede virkning
MDN forklarer idempotens som samme tilsigtede effekt ved ét eller flere identiske kald. PUT og DELETE har den egenskab efter HTTP-specifikationen; POST og PATCH har den ikke som udgangspunkt. Det er en egenskab ved handlingen, ikke et løfte om nul omkostninger eller identiske svar.
Tag CRM-eksemplet: Henvendelsen får nummer 142. Målet er én sag med det nummer. To medarbejdere kan komme til at starte samme oprettelse næsten samtidig, eller et system kan gentage den efter et forbindelsesbrud. Skriv den ønskede sluttilstand ind i jeres test: Der skal fortsat være én sag, og I skal kunne se, hvilke forsøg der førte frem til den.
Prøv også de trin, der kommer bagefter. Hvad sker der med kvitteringsmailen og den interne opgave, når CRM-trinnet køres igen? En eksisterende sag er ikke i sig selv bevis på, at mailen er sendt. Giv hvert trin sit eget resultat i journalen, så en kollega kan skelne mellem oprettet sag, sendt mail og et trin, der stadig venter.
Nøglen skal håndhæves ét sted
Det oplagte greb er en fast nøgle på hver henvendelse, for eksempel mailens id, så flowet slår op på nøglen og opdaterer i stedet for at oprette. Nøglen er nødvendig, men opslaget alene holder ikke. Kører to kopier af flowet samtidig, kan de begge nå at slå op, begge få tomt svar og begge oprette. Der er ikke noget, der afgør kapløbet.
Brug først modtagerens egen idempotensfunktion eller en unikhedsregel på henvendelsens nøgle, hvis systemet tilbyder det. Undersøg, hvad funktionen faktisk dækker: både gentagne og samtidige forsøg, og hvor længe nøglen huskes. En lokal tabel med et unikt nummer kan fordele arbejdet mellem jeres egne kørsler. Den kan ikke alene garantere, hvad et eksternt CRM har nået at gøre.
Et ukendt svar skal afklares
Forestil jer, at CRM-systemet opretter sagen, men forbindelsen forsvinder, før jeres flow modtager svaret. Eller at flowet stopper efter at have reserveret nummeret lokalt, men før sagen bliver oprettet. I begge tilfælde mangler I et sikkert resultat. Markér forsøget som ukendt, gem henvendelsens nummer og tidspunkt, og lad en navngiven person eller en dokumenteret afstemning undersøge modtagerens tilstand.
RFC 9110 siger, at et ikke-idempotent kald ikke bør gentages automatisk, medmindre klienten ved, at handlingen er idempotent, eller kan fastslå, at det første forsøg ikke blev anvendt. Derfor skal jeres fejlplan kunne stoppe og afklare udfaldet. En blind genafsendelse er ikke en løsning på et manglende svar.
Tre steder, hvor et menneske skal se efter
Det første er alt, der forlader huset. Når vi behandler fakturaer, kontrolleres totalen altid uden om modellen, før den lander som klar til godkendelse, netop fordi en model kan læse et tal forkert. Samme princip kan I lægge på mails til kunder og posteringer i bogholderiet: beløb og modtager skal kunne ses af et menneske, før de går videre.
Det andet er undtagelseskøen. Den skal have en navngiven ejer og et fast tidspunkt på dagen. En kø, alle kan se, og ingen har ansvaret for, bliver ikke tømt.
Det tredje er driften. Vi bygger flows med overvågning og fejlalarmer, som kan give besked, når noget fejler, men nogen skal stadig tage imod beskeden om, at et flow er stoppet i nat. Aftal, hvem der kigger på loggen, og hvor tit.
Næste skridt er lille nok til i dag: tag ét flow, skriv trinnene op, og sæt et kryds ved hvert trin, der kan køre to gange uden en ekstra tilsigtet virkning. For dem uden kryds finder I nøglen og beslutter, hvilket system der håndhæver, at nøglen kun findes én gang. Resten af bygningen bliver lettere, når den øvelse er lavet først.
Ofte stillede spørgsmål
Hvad sker der, hvis automatiseringen kører det samme trin to gange?
Prøv det på en testhenvendelse, før flowet får adgang til rigtige kunder. Kontrollér både sagen, kvitteringsmailen og den interne opgave. Det er de samlede resultater, I skal kunne forklare, når en kollega spørger, hvad der skete.
Hvordan undgår vi, at den samme henvendelse bliver oprettet to gange i CRM'et?
Dubletter i CRM'et holdes bedst ude af det system, der modtager data: giv hver henvendelse en fast nøgle, og lad modtagersystemet håndhæve, at nøglen kun kan findes én gang. Et opslag i flowet, før sagen oprettes, er ikke nok i sig selv, for to samtidige kørsler kan begge nå at slå op forgæves og begge oprette.
Hvad gør vi, når CRM-systemet ikke svarer?
Registrér udfaldet som ukendt og undersøg den konkrete henvendelse i CRM-systemet. Et manglende svar fortæller ikke, om sagen blev oprettet. Send ikke oprettelsen igen alene for at få et tydeligere svar.
Skal et menneske godkende alt, hvad en automatisering laver?
Et menneske behøver ikke godkende hvert enkelt trin i en automatisering, men bør se det, der forlader huset, altså beløb, modtagere og posteringer. Når vi behandler fakturaer, kontrolleres totalen altid uden om modellen, før den lander som klar til godkendelse.
Hvad gør vi med de henvendelser, automatiseringen ikke kan behandle?
Henvendelser, automatiseringen ikke kan behandle, hører hjemme i en synlig kø med en navngiven ejer og et fast tidspunkt på dagen. Så bliver de set af et menneske i stedet for at blive kasseret i stilhed, og I kan se, hvor tit flowet støder på noget, det ikke kan afgøre.
Kilder
- MDN Web Docs: Idempotent. Begrebet og forskellen mellem HTTP-metoder. Læst 8. september 2026.
- RFC 9110, afsnit 9.2.2. Grænsen for automatisk gentagelse af ikke-idempotente kald. Læst 8. september 2026.
- Platformhuset: Integration og automatisering. Systemforbindelser, overvågning og kontrol af fakturatotaler. Læst 8. september 2026.
- Platformhuset: Send en ide. Opgaven beskrevet med egne ord. Læst 8. september 2026.
