Ik merk vaak dat ik Automatiseringen wil gebruiken, maar beperkt word door hoe ze momenteel werken. Vaak bevat een script iets dat ik nodig heb, terwijl ik dat deel nodig heb om te werken binnen de context van een ander script.
Het lijkt erop dat dit grotendeels te maken heeft met de manier waarop Automatiseringen momenteel werken en zijn ingesteld. Ik zou graag zien dat dingen worden opgesplitst in Triggers en Acties.
Voorbeeld triggers:
Wanneer een onderwerp wordt aangemaakt/bijgewerkt
Wanneer een bericht wordt aangemaakt/bijgewerkt
Wanneer een site-instelling wordt gewijzigd
Wanneer een onderwerp wordt gesloten
Wanneer een gebruiker een badge verdient
etc.
Voorbeeld acties:
Maak een banneronderwerp
Sluit een onderwerp
Reageer op een onderwerp
Maak een onderwerp aan
Tag een onderwerp
Voer LLM-aanroep uit
Stuur een Slack-bericht
etc.
Deze opzet zou een paar dingen mogelijk maken:
Meerdere acties die na een trigger kunnen worden toegewezen (bijv. Wanneer onderwerp wordt aangemaakt > Voer LLM-aanroep uit > Tag bericht > Reageer op het onderwerp)
Sta toe dat trigger-payloadgegevens (en daaropvolgende gegevens die beschikbaar worden gesteld door acties - bijv. LLM-aanroeprespons) dynamisch binnen acties worden gebruikt.
Uiteindelijk denk ik dat Automatisering veel potentieel heeft, maar elk script is op een manier geïsoleerd dat het erg moeilijk is om aan individuele behoeften aan te passen. Elk gaat er momenteel van uit dat de beschikbare acties voor iedereen zullen werken.
I like this proposal a lot! It seems to solve most (if not all) of the pain points automations currently have.
It also feels much more scalable for new Triggers and Actions. I imagine this opening the doors for easily adding additional triggers - like theme_created or theme_updated - without having to worry about how they interact with pre-existing scripts. New triggers would instantly gain access to every existing action (Slack notifications, PMs, LLM calls, etc.). The same applies to creating additional actions like assign_badge, add_to_group, add_to_logs_and_screening and so on.
Ohhhh, and “Dry run” and “Execution logs” are also spot on - having that level of observability into how things actually run is a total life saver.
Just hopping on quickly: in addition to the trigger/filter/action, being able to add delays would be precious.
(Example: onboarding/nudges, send message one week after joining community, then two months later, or if member hasn’t posted or read etc x days after joining do something… definitely not something any community would use, but for the active support community type like ours, it would be!)
While this is still in the conceptual phase, I’ll continue to keep brainstorming on it
Regarding conditions, I’ve been wondering how much flexibility could actually be built in. It would be great to implement something like the screenshot, where the user has full control over how criteria are constructed. Allowing users to select data from the trigger_context, define how it’s evaluated, and set what it’s evaluated against - while also letting them choose between AND / OR logic.
It would unlock more complex scenarios, whilst also keeping it easy and intuitive to understand like:
if {{category}} is one of {{user selected value}}AND
if {{tag}} is not {{user selected value}}
The screenshot also includes what to do after the condition check, but this would probably only apply for branched pipelines - for a linear pipeline, which covers most cases, then it would probably simply end
