אני מוצא את עצמי לעיתים קרובות רוצה להשתמש באוטומציות, אך מרגיש מוגבל על ידי האופן שבו הן פועלות כיום. אני מוצא לעיתים קרובות שסקריפט אחד מכיל משהו שאני צריך, בעוד שאני צריך שחלק זה יעבוד בהקשר של סקריפט אחר.
נראה שזה קשור במידה רבה לאופן שבו אוטומציות פועלות ומוגדרות כיום. אשמח לראות דברים מופרדים לטריגרים (Triggers) ופעולות (Actions).
טריגרים לדוגמה:
כאשר נוצר/מתעדכן נושא (topic)
כאשר נוצר/מתעדכן פוסט
כאשר מוגדר אתר משתנה
כאשר נושא נסגר
כאשר משתמש זוכה בתג (badge)
וכו’.
פעולות לדוגמה:
יצירת נושא באנר
סגירת נושא
מענה לנושא
יצירת נושא
תיוג נושא
הפעלת קריאת LLM (מודל שפה גדול)
שליחת הודעה ל-Slack
וכו’.
הגדרה זו תאפשר מספר דברים:
הקצאת מספר פעולות בעקבות טריגר (למשל, כאשר נושא נוצר > הפעלת קריאת LLM > תיוג פוסט > מענה לנושא)
לאפשר לנתוני המטען של הטריגר (ולנתונים זמינים נוספים מפעולות - למשל, תגובת קריאת LLM) לשמש באופן דינמי בפעולות.
בסופו של דבר, אני מרגיש שלאוטומציות יש פוטנציאל רב, אך כל סקריפט נמצא במערכת נפרדת (siloed) באופן שמקשה מאוד על התאמה אישית לצרכים אינדיבידואליים. כל אחד כיום מניח שהפעולות הזמינות יעבדו עבור כולם.
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
