A menudo me encuentro queriendo usar Automatizaciones, pero sintiéndome limitado por cómo funcionan actualmente. Con frecuencia encuentro que un script tiene algo que necesito, mientras que necesito que esa parte funcione dentro del contexto de otro script.
Parece que esto está en gran medida relacionado con la forma en que las Automatizaciones funcionan y se configuran actualmente. Me encantaría ver las cosas divididas en Disparadores y Acciones.
Disparadores de ejemplo:
Cuando se crea/actualiza un tema
Cuando se crea/actualiza una publicación
Cuando cambia una configuración del sitio
Cuando se cierra un tema
Cuando un usuario gana una insignia
etc.
Acciones de ejemplo:
Crear un tema de banner
Cerrar un tema
Responder a un tema
Crear un tema
Etiquetar un tema
Ejecutar llamada LLM
Enviar un mensaje de Slack
etc.
Esta configuración permitiría algunas cosas:
Múltiples acciones que se asignarán después de un disparador (por ejemplo, Cuando se crea un tema > Ejecutar llamada LLM > Etiquetar publicación > Responder al tema)
Permitir que los datos de carga útil del disparador (y los datos posteriores disponibles de las acciones, por ejemplo, la respuesta de la llamada LLM) se utilicen dinámicamente dentro de las acciones.
En última instancia, siento que Automatización tiene mucho potencial, pero cada Script está aislado de una manera que hace que sea muy difícil de personalizar para las necesidades individuales. Cada uno asume actualmente que las acciones disponibles funcionarán para todos.
¡Me gusta mucho esta propuesta! Parece resolver la mayoría (si no todos) de los puntos débiles que tienen actualmente las automatizaciones.
También se siente mucho más escalable para nuevos Desencadenadores (Triggers) y Acciones (Actions). Me imagino que esto abrirá las puertas para añadir fácilmente desencadenadores adicionales, como theme_created o theme_updated, sin tener que preocuparse por cómo interactúan con los scripts preexistentes. Los nuevos desencadenadores obtendrían acceso instantáneo a todas las acciones existentes (notificaciones de Slack, mensajes privados, llamadas a LLM, etc.). Lo mismo aplica para crear acciones adicionales como assign_badge, add_to_group, add_to_logs_and_screening, y así sucesivamente.
¡Ohhh, y la “Ejecución de prueba” (Dry run) y los “Registros de ejecución” (Execution logs) también son acertados! Tener ese nivel de observabilidad sobre cómo funcionan realmente las cosas es un salvavidas total.
Solo un comentario rápido: además del disparador/filtro/acción, poder añadir retrasos sería muy valioso.
(Ejemplo: incorporación/recordatorios, enviar mensaje una semana después de unirse a la comunidad, y luego dos meses después, o si el miembro no ha publicado o leído, etc., hacer algo x días después de unirse… definitivamente no es algo que cualquier comunidad usaría, ¡pero para el tipo de comunidad de soporte activo como la nuestra, lo sería!)
Aunque esto todavía está en fase conceptual, seguiré pensando en ello
Con respecto a las condiciones, me he estado preguntando cuánta flexibilidad se podría incorporar realmente. Sería genial implementar algo como la captura de pantalla, donde el usuario tiene control total sobre cómo se construyen los criterios. Permitir a los usuarios seleccionar datos del trigger_context, definir cómo se evalúan y establecer contra qué se evalúan, al tiempo que les permite elegir entre la lógica AND / OR.
Esto desbloquearía escenarios más complejos, a la vez que seguiría siendo fácil e intuitivo de entender, como:
si {{category}} es uno de {{user selected value}}Y
si {{tag}} no es {{user selected value}}
La captura de pantalla también incluye qué hacer después de la comprobación de la condición, pero esto probablemente solo se aplicaría a pipelines ramificadas; para un pipeline lineal, que cubre la mayoría de los casos, probablemente simplemente terminaría
