Frequentemente me vejo querendo usar Automações, mas me sinto limitado pela forma como elas funcionam atualmente. Muitas vezes encontro um script com algo que preciso, enquanto preciso que essa parte funcione no contexto de outro script.
Parece que isso está amplamente relacionado à maneira como as Automações funcionam e são configuradas atualmente. Eu adoraria ver as coisas divididas em Gatilhos e Ações.
Exemplos de gatilhos:
Quando um tópico é criado/atualizado
Quando uma postagem é criada/atualizada
Quando uma configuração do site muda
Quando um tópico é fechado
Quando um usuário ganha um distintivo
etc.
Exemplos de ações:
Criar um tópico de banner
Fechar um tópico
Responder a um tópico
Criar um tópico
Marcar um tópico com tag
Executar chamada LLM
Enviar uma mensagem para o Slack
etc.
Essa configuração permitiria algumas coisas:
Múltiplas ações a serem atribuídas após um gatilho (por exemplo, Quando tópico é criado > Executar chamada LLM > Marcar postagem com tag > Responder ao tópico)
Permitir que dados de payload do gatilho (e dados subsequentes disponibilizados pelas ações - por exemplo, resposta da chamada LLM) sejam usados dinamicamente dentro das ações
Em última análise, sinto que Automação tem muito potencial, mas cada Script está isolado de uma forma que torna muito difícil personalizá-lo para necessidades individuais. Cada um assume atualmente que as ações disponíveis funcionarão para todos.
Gosto muito desta proposta! Parece resolver a maioria (se não todos) dos pontos problemáticos que as automações têm atualmente.
Também parece muito mais escalável para novos Gatilhos (Triggers) e Ações (Actions). Imagino que isso abrirá as portas para adicionar facilmente gatilhos adicionais - como theme_created ou theme_updated - sem ter que se preocupar com a forma como interagem com scripts pré-existentes. Novos gatilhos ganhariam instantaneamente acesso a todas as ações existentes (notificações do Slack, MPs, chamadas de LLM, etc.). O mesmo se aplica à criação de ações adicionais como assign_badge, add_to_group, add_to_logs_and_screening e assim por diante.
Ahhh, e “Execução de teste” (Dry run) e “Logs de execução” (Execution logs) também são perfeitos - ter esse nível de observabilidade sobre como as coisas realmente funcionam é uma salvação total.
Apenas passando rapidamente: além do gatilho/filtro/ação, poder adicionar atrasos seria precioso.
(Exemplo: integração/incentivos, enviar mensagem uma semana após ingressar na comunidade, depois dois meses depois, ou se o membro não postou ou leu, etc., x dias após ingressar, faça algo… definitivamente não é algo que qualquer comunidade usaria, mas para o tipo de comunidade de suporte ativo como a nossa, seria!)
Embora isto ainda esteja na fase conceitual, continuarei a fazer brainstorming sobre isso
Em relação às condições, tenho me perguntado quanta flexibilidade poderia ser realmente incorporada. Seria ótimo implementar algo como a captura de tela, onde o usuário tem controle total sobre como os critérios são construídos. Permitir que os usuários selecionem dados do trigger_context, definam como eles são avaliados e definam contra o que são avaliados - ao mesmo tempo em que lhes permitem escolher a lógica AND / OR.
Isso desbloquearia cenários mais complexos, ao mesmo tempo em que manteria a facilidade e a intuição de entender, como:
se {{category}} for um de {{user selected value}}E
se {{tag}} não for {{user selected value}}
A captura de tela também inclui o que fazer após a verificação da condição, mas isso provavelmente só se aplicaria a pipelines ramificados - para um pipeline linear, que cobre a maioria dos casos, então provavelmente simplesmente terminaria
