Als dit gebeurt, dan dat

Gebeurtenissen om op te reageren

Een regel begint bij zijn trigger: de gebeurtenis waarop hij luistert, één per regel. Die gebeurtenissen komen uit de modules zelf en niet uit een laag ernaast, dus een klant die je in een spreadsheet op 'actief' zet vuurt precies dezelfde regel als een klant die je in het scherm op 'actief' zet. Wil je op twee dingen reageren, dan maak je twee regels; elke regel heeft zijn eigen aan/uit-schakelaar in de lijst, zodat je er één stil kunt leggen zonder hem te verwijderen. In het keuzemenu staan naast deze zes nog twee recepten die vandaag nog niets doen (de uptime-schakelaar van een website en de status van een domein): de regel is vast te bouwen, maar er komt pas iets binnen zodra die modules de gebeurtenis gaan uitzenden.

• Een taak wordt aangemaakt
• Een taak verandert van status
• Een taak wordt toegewezen
• Een klant wordt toegevoegd
• Een klant verandert van status
• Een project verandert van status

Voorwaarden die je klikt, geen code die je schrijft

Onder de trigger bouw je rijen van Veld, operator en Waarde, met de keuze tussen "Alle voorwaarden moeten kloppen" en "Minstens één voorwaarde moet kloppen". Ze worden gecontroleerd tegen de gebeurtenis én tegen het record waar die over gaat, dus je kunt zowel op de overgang als op de huidige waarden filteren. Geen voorwaarden betekent: de regel vuurt altijd. Voor geneste alle/één-van-bomen is er "Geavanceerd: voorwaarden als JSON bewerken", met directe controle op geldige JSON. Wat er bewust níét is, is een codeveld: een uitvoerbaar script in een beheerscherm op je eigen server is een lek met extra stappen, dus voorwaarden zijn declaratief en blijven dat.

• is gelijk aan · is niet gelijk aan
• is één van (waarden gescheiden door komma's)
• bevat
• is groter dan · is kleiner dan

Vijf acties, op volgorde uitgevoerd

Klopt de regel, dan draaien de acties op volgorde in de achtergrondworker. Elke actie draait in zijn eigen savepoint: mislukt er één, dan stopt de keten daar, wordt alleen die stap teruggedraaid en staat de uitvoering op Mislukt. Wat de stappen ervóór al deden blijft staan, want half toegepast is eerlijker dan stilletjes ongedaan gemaakt. Andere modules kunnen hun eigen acties bijdragen, dus de lijst kan groeien zonder dat er aan automatisering zelf iets verandert. Een regel zonder acties mag ook: die matcht en logt, en doet verder niets.

• Taak aanmaken: één losse taak, of een heel taaksjabloon op de klant waarop de regel vuurde
• Taakstatus wijzigen
• Taak toewijzen
• Melding sturen: naar de collega's die je aanwijst, met je eigen tekst
• Webhook aanroepen

Een webhook die het antwoord meetelt

De webhookactie post de gebeurtenis, het entiteitstype, het id en de payload als JSON naar de URL die je invult, klaar voor n8n, Make of je eigen endpoint. Zet je "Wachten op bevestiging" aan, dan is het geen los schot maar een handdruk: de uitvoering faalt tenzij het endpoint met 2xx antwoordt en niet {"ok": false} teruggeeft. Omdat die URL door een mens is ingetypt en het verzoek van jouw eigen server vertrekt, wordt de hostnaam eerst opgezocht en moet elk adres waarop hij uitkomt publiek zijn; loopback, privénetwerken en link-local worden geweigerd, redirects worden niet gevolgd en er staat een harde time-out op. Draait je automatiseringsserver bewust op het LAN, dan zet de beheerder die uitzondering expliciet aan.

Testrun vooraf, uitvoerlog achteraf

Voordat je een regel aanzet, draai je een Testrun tegen het id van een bestaand record: je ziet of de voorwaarden kloppen en welke acties zouden vuren, en er wordt niets uitgevoerd. Daarna houdt het Uitvoerlog alles bij: wanneer, welke regel, welke trigger, de status, de uitkomst per stap, de foutmelding en de ketendiepte, te filteren op één regel. Verwijder je een regel, dan blijft die geschiedenis staan; het verwijdervenster zegt dat er ook bij. Een uitvoering die de wachtrij nooit haalde, bijvoorbeeld door een hapering in Redis, wordt door een sweep opnieuw aangeboden in plaats van stil te blijven liggen.

• In wachtrij · Bezig · Geslaagd · Mislukt · Overgeslagen

Regels die elkaar niet gek maken

Een regel die een taak aanmaakt, vuurt een gebeurtenis waar een andere regel weer op kan reageren. Dat mag, maar niet eindeloos: een gebeurtenis die drie automatiseringssprongen diep is wordt als Overgeslagen vastgelegd in plaats van uitgevoerd, dus regel A → B → A is zichtbaar in het log en geen storing; dezelfde gebeurtenis die twee keer binnenkomt krijgt dezelfde sleutel en levert geen tweede uitvoering op. Regels schrijven is standaard alleen voor beheerders, want een regel handelt namens de organisatie: hij maakt taken aan, stuurt meldingen en roept externe endpoints aan. Regels lezen, regels schrijven en het log lezen zijn daarom drie losse rechten, per rol te verruimen onder Instellingen → Rollen. Automatisering is een uitbreidingsmodule: de kern van schakl. is open source (AGPL-3.0), uitbreidingsmodules vragen een licentiesleutel die je onder Instellingen → Licentie invult.