Operator actions
Define tareas seguras que Polaris Operator puede ejecutar o preparar para tu equipo.
Una action es una tarea o proceso que Polaris Operator puede ejecutar automáticamente o preparar para revisión humana.
Sirve para convertir una conversación en trabajo concreto, como crear un lead, actualizar una reserva, enviar una notificación, llamar un webhook o preparar una tarea para un equipo.
Ejemplos comunes
- Crear un lead para seguimiento comercial.
- Preparar una solicitud de cita.
- Crear una tarea de soporte.
- Enviar una notificación interna.
- Actualizar el estado de una reserva.
- Conectar la conversación con otra herramienta.
Cómo configurarlas
- Define el resultado que debe producir la action.
- Lista la información mínima que necesita.
- Decide si requiere approval humana.
- Prueba el flujo con datos reales.
- Publica primero para un caso de bajo riesgo.
- Revisa resultados antes de ampliar el uso.
Tools y reglas de ejecución
Una tool es una capacidad específica que Operator puede usar cuando una conversación necesita convertirse en trabajo. Activar una tool significa permitir que Polaris prepare o ejecute esa acción dentro del workspace, respetando las reglas configuradas.
Las reglas de ejecución definen cómo se comporta una tool:
- Aprobación humana: Operator prepara la acción, pero espera a que una persona la apruebe antes de ejecutarla.
- Ejecución inmediata: la acción se ejecuta en el momento si la política lo permite.
- Ejecución en segundo plano: la acción queda como job para continuar fuera del turno de conversación.
- Horario laboral: la acción solo puede ejecutarse dentro de una ventana horaria definida.
Presets recomendados
En Operator -> Tools -> Configurar, Polaris ofrece presets para evitar editar JSON:
- Default seguro: requiere aprobación humana y ejecuta en segundo plano. Es la opción recomendada para empezar.
- Bajo riesgo interno: ejecuta inmediatamente sin aprobación. Úsalo solo en acciones internas de bajo impacto, como etiquetar conversaciones en un workspace controlado.
- Horario laboral: permite ejecutar solo dentro del horario definido y requiere aprobación.
Los presets actualizan las reglas en pantalla, pero no guardan automáticamente. Debes presionar Guardar cambios.
Integraciones externas
Tools como generic_webhook y send_email requieren más cuidado porque pueden enviar datos fuera de Polaris.
generic_webhook llama un endpoint HTTPS externo mediante POST. Puede usar secrets con la sintaxis {{secret:nombre_del_secret}} para no exponer credenciales. Por seguridad, los webhooks siempre requieren aprobación y ejecución en segundo plano, aunque la regla indique otra cosa.
Un usuario no técnico no debería editar JSON avanzado, headers, payloads ni secrets sin apoyo técnico. Usa el modo básico siempre que sea posible.
Configuración avanzada
La sección avanzada muestra Policy JSON para administradores técnicos.
Policy JSON controla reglas reales como aprobación, modo de ejecución y horario. La configuración avanzada de tool queda reservada para futuras fases y no es necesaria para usuarios no técnicos.
Buenas prácticas
Diseña cada action con un objetivo claro. Mientras más específica sea, más fácil será probarla, revisarla y mantenerla bajo control.
- Nombra la action por el resultado que produce.
- Pide solo la información necesaria para ejecutarla.
- Evita acciones demasiado amplias o ambiguas.
- Usa approvals cuando la action pueda afectar a un cliente, una cita o información importante.
- Diseña acciones que puedan ejecutarse de forma segura sin crear resultados duplicados.
Ejemplos de actions
| Action | Uso típico |
|---|---|
| create_lead | Captura de prospectos |
| booking_request | Solicitud de cita |
| send_notification | Alertas internas |
| create_support_task | Seguimiento por soporte |
| update_booking_status | Cambios en una reserva |
Seguridad y trazabilidad
Operator no debe ejecutar acciones sensibles “a ciegas”. Polaris registra las acciones importantes para que tu equipo pueda revisar qué se intentó hacer, cuándo ocurrió y cuál fue el resultado.
Esto ayuda a mantener control cuando una automatización falla, queda pendiente o necesita intervención humana.
Cuando algo falla
Cada action debe terminar con un estado claro para que el equipo sepa si se completó, falló o necesita revisión.
Si una action no puede completarse, Polaris debe dejar suficiente contexto para que una persona pueda continuar sin empezar desde cero.
Qué evitar
- Acciones demasiado amplias como “resolver todo”.
- Pedir datos que no son necesarios.
- Ejecutar acciones sensibles sin approval.
- Automatizar antes de revisar resultados reales.
Relación con otros módulos
Actions suelen trabajar con Chatbots, Approvals, Jobs, Booking y canales como WhatsApp o Web Widget.
El chatbot detecta la necesidad, Operator prepara la action, Approvals protegen decisiones sensibles y Jobs pueden continuar el trabajo en segundo plano.
