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.
이 제안이 정말 마음에 듭니다! 현재 자동화가 가진 대부분의 (아니면 모든) 문제점을 해결하는 것 같습니다.
새로운 트리거와 액션에 대해서도 훨씬 더 확장성이 높아 보입니다. theme_created나 theme_updated와 같은 추가 트리거를 쉽게 추가할 수 있게 되어, 기존 스크립트와의 상호작용에 대해 걱정할 필요가 없게 될 것 같습니다. 새로운 트리거는 즉시 모든 기존 액션(Slack 알림, 개인 메시지, LLM 호출 등)에 접근할 수 있게 됩니다. assign_badge, add_to_group, add_to_logs_and_screening과 같은 추가 액션을 생성하는 경우에도 마찬가지입니다.
아, 그리고 "Dry run"과 "Execution logs"도 정말 딱 맞습니다. 실제로 실행되는 방식에 대한 이러한 수준의 관찰 가능성을 가질 수 있다는 것은 정말 큰 도움이 됩니다.
간단히 말씀드리면: 트리거/필터/액션 외에 지연 시간을 추가할 수 있으면 정말 유용할 것입니다.
(예: 온보딩/알림을 위해 커뮤니티 가입 후 1주일에 메시지를 보내고, 그 후 2개월 뒤에 다시 보내거나, 가입 후 x일 동안 게시글을 쓰지 않거나 읽지 않은 경우 특정 작업을 수행하는 것 등… 아마 대부분의 커뮤니티에서는 사용하지 않을 기능이지만, 우리처럼 능동적인 지원 커뮤니티에서는 꼭 필요한 기능일 것입니다!)
조건에 대해 생각해보니, 실제로 얼마나 유연성을 부여할 수 있을지 궁금했습니다. 스크린샷과 같이 사용자가 기준을 구성하는 방법에 대해 전권을 가질 수 있도록 구현하면 좋겠습니다. 사용자가 trigger_context에서 데이터를 선택하고, 평가 방식을 정의하며, 평가 대상 값을 설정할 수 있도록 하는 것이지요. 여기에 AND / OR 논리 선택도 가능하게 하면 됩니다.
이를 통해 더 복잡한 시나리오를 가능하게 하면서도, 다음과 같이 이해하기 쉽고 직관적인 구조를 유지할 수 있습니다:
{{category}}가 AND
{{tag}}가 {{user selected value}}가 아니면
스크린샷에는 조건 확인 후 수행할 동작도 포함되어 있지만, 이는 아마도 분기된 파이프라인에만 적용될 것입니다. 대부분의 경우를 차지하는 선형 파이프라인의 경우, 아마도 단순히 종료될 것입니다.
