Spesso mi trovo a voler usare l’Automazione, ma sento di essere limitato da come funzionano attualmente. Spesso trovo che uno script abbia qualcosa di cui ho bisogno, mentre ho bisogno che quella parte funzioni nel contesto di un altro script.
Sembra che ciò sia in gran parte correlato al modo in cui le Automazioni funzionano e sono configurate attualmente. Mi piacerebbe vedere le cose divise in Trigger e Azioni.
Esempi di trigger:
Quando un argomento viene creato/aggiornato
Quando un post viene creato/aggiornato
Quando un’impostazione del sito cambia
Quando un argomento viene chiuso
Quando un utente guadagna un badge
ecc.
Esempi di azioni:
Crea un argomento banner
Chiudi un argomento
Rispondi a un argomento
Crea un argomento
Tagga un argomento
Esegui chiamata LLM
Invia un messaggio Slack
ecc.
Questa configurazione consentirebbe alcune cose:
Molteplici azioni da assegnare a seguito di un trigger (ad es. Quando viene creato un argomento > Esegui chiamata LLM > Tagga post > Rispondi all’argomento)
Consentire l’uso dinamico dei dati del payload del trigger (e dei dati successivi resi disponibili dalle azioni - ad es. risposta alla chiamata LLM) all’interno delle azioni
In definitiva, ritengo che l’Automazione abbia un grande potenziale, ma ogni script è isolato in un modo che rende molto difficile personalizzarlo in base alle esigenze individuali. Ognuno presume attualmente che le azioni disponibili funzioneranno per tutti.
Apprezzo molto questa proposta! Sembra risolvere la maggior parte (se non tutti) i punti dolenti che le automazioni hanno attualmente.
Inoltre, sembra molto più scalabile per i nuovi Trigger e Azioni. Immagino che questo apra le porte per aggiungere facilmente trigger aggiuntivi - come theme_created o theme_updated - senza doversi preoccupare di come interagiscono con gli script preesistenti. I nuovi trigger otterrebbero immediatamente accesso a ogni azione esistente (notifiche Slack, messaggi privati, chiamate LLM, ecc.). Lo stesso vale per la creazione di azioni aggiuntive come assign_badge, add_to_group, add_to_logs_and_screening e così via.
Ohhh, e anche “Dry run” (Simulazione) e “Execution logs” (Log di esecuzione) sono perfetti: avere quel livello di osservabilità su come funzionano le cose è un vero toccasana.
Passo solo un attimo per dire: oltre a trigger/filtro/azione, poter aggiungere ritardi sarebbe prezioso.
(Esempio: onboarding/sollecitazioni, invia messaggio una settimana dopo essersi uniti alla community, poi due mesi dopo, o se un membro non ha pubblicato o letto ecc. x giorni dopo essersi unito fai qualcosa… non è sicuramente qualcosa che qualsiasi community userebbe, ma per il tipo di community di supporto attivo come la nostra, lo sarebbe!)
Sebbene questo sia ancora in fase concettuale, continuerò a pensarci su
Per quanto riguarda le condizioni, mi sono chiesto quanta flessibilità si potrebbe effettivamente implementare. Sarebbe fantastico implementare qualcosa di simile allo screenshot, in cui l’utente ha il pieno controllo su come vengono costruiti i criteri. Consentire agli utenti di selezionare dati dal trigger_context, definire come vengono valutati e impostare contro cosa vengono valutati, consentendo loro anche di scegliere tra la logica AND / OR.
Sbloccherebbe scenari più complessi, pur mantenendo la facilità e l’intuitività di comprensione come:
if {{category}} is one of {{user selected value}}AND
if {{tag}} is not {{user selected value}}
Lo screenshot include anche cosa fare dopo il controllo della condizione, ma questo si applicherebbe probabilmente solo alle pipeline ramificate - per una pipeline lineare, che copre la maggior parte dei casi, allora probabilmente terminerebbe semplicemente
