I often find myself wanting to use Automation, but feeling limited by how they currently work. I often find one script has something I need, while I need that part to work within the context of another script.
It seems this is largely related to the way Automations currently work and are set up. I’d love to see things split into Triggers and Actions.
Example triggers:
When a topic is created/updated
When a post is created/updated
When a site setting changes
When a topic is closed
When a user earns a badge
etc.
Example actions:
Make a banner topic
Close a topic
Reply to a topic
Create a topic
Tag a topic
Run LLM call
Send a Slack message
etc.
This setup would allow for a few things:
Multiple actions to be assigned following a trigger (e.g. When topic is created> Run LLM Call> Tag post> Reply to the topic)
Allow for trigger payload data (and subsequent data made available from actions - e.g. LLM call response) to be used dynamically within actions
Ultimately, I feel Automation has a lot of potential, but each Script is siloed in a way that makes it very hard to customize to individual needs. Each currently assumes that the actions available will work for everyone.
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
