Nodos Trigger

Un trigger es cómo arranca una automatización. Toda automatización tiene exactamente uno, y la elección define dos cosas: cuándo corre el flujo, y con qué cuenta cuando lo hace.

Hay cinco.

Manual

Corre a pedido — desde el editor mientras probás, desde la API, o desde el nodo Call Automation de otra automatización.

Su contexto arranca vacío salvo por lo que le pase quien la llama. Eso lo vuelve la opción natural para un trabajo que alguien decide correr: una exportación mensual, un arreglo de datos, un reenvío.

Es además cómo se prueba el resto. Armá el flujo con un trigger manual, dejalo andando, y después cambiá al real.

Schedule

Se dispara en un horario o intervalo recurrente, en la zona horaria del workspace — no en UTC, lo que importa apenas "todos los días a las 9" tiene que significar las nueve donde está tu equipo.

Usalo para el trabajo que nadie debería tener que recordar: sincronizaciones nocturnas, correos de recordatorio, un resumen semanal, vencer registros viejos.

Lo que hay que diseñar es el solapamiento. Si una corrida agendada puede durar más que el intervalo entre corridas, decidí qué debería pasar — normalmente haciendo que el flujo sea seguro de correr dos veces, y no esperando que nunca ocurra.

Evento de sistema

Se dispara con un evento del workspace: una fila creada, una fila actualizada, una fila que cambia de estado.

Este es el trigger que hace que Praxsuite se sienta vivo. Cae una fila en Solicitudes y el flujo avisa a alguien; un estado pasa a Aprobado y sale la factura. Nadie llama a nada — el dato cambiando es el evento.

Dos cosas que conviene saber antes de depender de él:

• Que tu propia automatización escriba una fila también es un evento. Un flujo que actualiza la tabla que lo dispara puede dispararse a sí mismo. Filtrá por lo que cambió, o escribí en otra tabla.

• Los cambios de estado son su propio evento, distinto de una actualización general. Si solo te importa "pasó a Aprobado", decilo así en vez de reaccionar a cada edición y chequear después.

Webhook

Se dispara cuando un pedido HTTP entrante llega a la URL de esa automatización. Acepta el pedido, responde al instante, y hace el trabajo después.

Esa forma es exactamente la correcta para "otro sistema me está avisando que pasó algo" — un proveedor de pagos publicando un evento, un servicio de formularios reenviando un envío, un pipeline de CI reportando un build. Quien envía quiere un acuse rápido, no la opinión de tu lógica de negocio.

El cuerpo del pedido llega al contexto, en {{context.request.body}}.

Endpoint

Se dispara igual, y después mantiene la conexión abierta hasta que tu flujo produce un Response. Quien llama recibe lo que diga tu nodo Response — código de estado, headers, cuerpo.

Este es el que convierte una automatización en una API. Tu app la llama, espera, y usa la respuesta.

La plataforma valida el par: una automatización con endpoint debe tener exactamente un nodo Response, y una sin trigger de endpoint no puede tener ninguno.

Elegir entre webhook y endpoint

Son los dos que se confunden, así que:

Si a quien llama no le importa qué concluyó tu flujo, un webhook es mejor — se mantiene rápido por lento que sea el trabajo. Si necesita una respuesta, solo sirve un endpoint.

Siguiente

• Nodos de base de datos — leer y escribir filas

• Nodos de lógica — ramificación, bucles, y el nodo Response

• Lógica del lado del servidor — armar una API sobre el trigger de endpoint

Cómo se ve

La paleta a la izquierda del editor de automatizaciones, filtrada a Triggers. Arrastras uno de estos al canvas para empezar un grafo.

La insignia pequeña en cada nodo — 1 AU, 2 AU — es lo que cuesta una ejecución de ese nodo contra las unidades de automatización de tu plan. Vale leerla antes de armar un bucle alrededor de un nodo: el costo es por corrida de nodo, no por automatización.