Trigger

Trigger er den konkrete hændelse, som sætter en agent eller et workflow i gang. Det kan være en ny e-mail, en udfyldt formular, en ordre i webshoppen, en ny række i et regneark eller et klokkeslæt. Valget af trigger afgør, hvor hurtigt noget kører, hvor ofte det kører, og hvilke data der er tilgængelige, når flowet starter.

Sådan virker Trigger i praksis

En trigger er simpelthen starten på en arbejdsproces. Forestil dig, at en trigger er ringeklokken ved hoveddøren: når den ringer, handler I. I en automation kan handlingen være at flytte data, sende en besked, oprette en sag eller opdatere et regneark. Nogle triggere afventer noget udefra, andre tæller tiden, og nogle venter på, at en person trykker på en knap. Valget bestemmer også forsinkelsen: webhook-triggere reagerer typisk med det samme, tidsplaner kører efter en plan, og manuelle triggere kører kun, når en kollega vælger det.

Trigger-typer: webhook, tidsplan og manuel

Der er tre praktiske typer, du møder i Make, Zapier og lignende værktøjer:

• Webhook (hændelse): Et eksternt system sender en besked, når noget sker, fx en ny ordre. Det er det hurtigste, fordi flowet starter øjeblikkeligt.
• Tidsplan (cron): Flowet kører efter en plan, hvert minut, hver time eller på faste dage. Bruges når øjeblikkelig reaktion ikke er nødvendig eller når I vil samle opgaver.
• Manuel (knap): En person starter flowet med et klik. Sikkert og enkelt, når I vil kontrollere hvornår noget skal ske.

Valget påvirker hyppighed og omkostninger. Et flow, der kører hvert minut, tæller ofte mod jeres forbrug i Zapier/Make. En webhook udløser færre falske runs, men kræver at den eksterne tjeneste kan sende en besked. En manuel trigger koster tid for en medarbejder, men mindsker automatisk kørsel.

Hvorfor trigger er det første spørgsmål, når du åbner Make eller Zapier

Når du sætter en automation op, er spørgsmålet altid: "Hvad skal starte det?". Start her, før du vælger handlinger. Hvis du vælger forkert, får du enten forsinkelse, for mange kørsel eller dårlig datakvalitet. Tænk på hvor hurtigt I skal reagere, hvem der ejer dataene, og om systemet, der skal sende triggeren, kan gøre det teknisk. Spørg også: Hvad gør vi, hvis triggeren går i stå? Plan for fejllogning og en ansvarlig person.

Eksempel: Trigger hos en dansk virksomhed

En ordremodtager i en lille webshop sad midt i julesalget, tirsdag formiddag i december, med en mailkasse, der ringede non-stop. De satte en webhook-trigger på webshoppen, så hver ny ordre automatisk oprettede en sag i deres ordre-system og sendte en bekræftelse til kunden. Først gik noget galt: webshoppens webhook sendte kun nye ordrer og ikke ændringer, så annullerede ordrer blev stadig behandlet. Løsningen var at tilføje en tidsplan, der dagligt sammenlignede ordrer og rydde op i fejl. Resultatet: ordremodtageren fik færre gentagne opgaver, men projektet krævede to halve dage til fejlsøgning og en opfølgende daglig check i den første uge.

Hvad du skal være opmærksom på

Vær konkret med hvilken hændelse der skal tælle som trigger: er det "ny post" i et regneark, eller "kolonne X ændret"? Overvej datakvalitet, en trigger med mangelfulde felter skaber fejl længere nede i flowet. Tænk også over om triggeren må gentage sig: nogle systemer sender flere events for samme sag. Endelig, husk at triggere kan koste i både licensforbrug og tid: flere runs betyder højere regning. En trigger er effektiv, men den er ikke en trylleformular.

Skal der køre noget med trigger hver dag og ikke kun i et forsøg, er det opgaven for et AI-team i huset. Vil I arbejde videre med trigger på jeres egne opgaver, er det dét, en AI-workshop går ud på.