Triggers

Los nombres de la primera columna son los de la paleta. Dos triggers distintos se llaman "Ejecución manual" allí: el de Utilidades es el trigger manual con su formulario; el que está en el menú desplegable de cada registro, en el grupo Filmo, es el trigger "desde un registro".

• Un trigger solo empieza a hacer algo después de que «Publicar». El editor reconstruye la tabla de consulta que decide qué se dispara cuando se publica una versión, nunca cuando se autoguarda un borrador.
• Los automáticos (agenda, webhook, evento, señal) también necesitan el «Live» activar. Un workflow pausado, archivado o nunca publicado no dispara nada.
• Los triggers manual, desde un registro y desde otro workflow no dependen de Live en el motor: un workflow pausado todavía se puede ejecutar desde el editor, mediante la API o llamado desde otro workflow. La página del registro y el panel también listan esos workflows, pero uno pausado o nunca publicado aparece en gris con el motivo y no se puede ejecutar desde allí.

Úsalo para trabajo que alguien inicia a propósito, o para un workflow que tu propio sistema inicia mediante el REST API o MCP. Declara el formulario en el trigger: cada campo tiene un nombre, una etiqueta y un tipo (el editor ofrece booleano, número, texto y fecha).

• Los nombres de campo empiezan por una letra o un guion bajo y solo usan letras, dígitos y guiones bajos. createdAt y createdBy están reservados, porque el trigger los publica él mismo, y un nombre no se puede repetir.
• Hay que enviar todos los campos declarados cuando alguien ejecuta el workflow (la API rechaza con 422 el que falte). No hay campos opcionales ni valores por defecto, aunque el formulario no te impide dejar vacío un campo de texto. Un workflow sin campos se ejecuta directamente, sin diálogo.
• Solo los administradores pueden ejecutar un workflow. Al pulsar el botón desde el editor se publica primero si el borrador tiene cambios.
• El trigger publica trigger_createdAt (cuándo se puso en cola la ejecución) y trigger_createdBy, además de una variable por cada campo. trigger_createdBy es el creador del workflow, no la persona que pulsó el botón.

Un workflow con este trigger aparece en «Ejecutar workflow» en el menú de acciones de la página del registro (y en la búsqueda de acciones rápidas), para administradores. No tiene formulario: recibe el propio registro. Un workflow está ligado a un tipo de registro (la lista está en la página de referencia del trigger), y el tipo no se puede cambiar una vez elegido, porque las expresiones se refieren a él.

• El registro se comprueba antes de poner la ejecución en cola y se vuelve a cargar cuando la ejecución empieza. Si se eliminó entretanto, la ejecución falla con "the record the workflow was launched on no longer exists".
• El trigger publica los mismos campos que los triggers de evento de ese registro (véase más abajo), bajo trigger_<record>.
• Mediante la API REST necesita el id del registro en payload.entityId; sin él se rechaza la petición.

Tiene el mismo formulario que el trigger manual, pero sin botón ni API: solo una «Disparar workflow» paso de otro workflow puede iniciarlo. Eso lo convierte en una llamada con contrato: quien llama elige el destino y rellena su formulario. Pulsar el botón, o llamar a la API, responde 409. Quien llama no espera el resultado; consulta Señales y encadenamiento de workflows.

Úsalo para trabajo que ocurre según el reloj. Indicas una expresión cron y una zona horaria. Funciona una expresión estándar de cinco campos, y también una de seis campos (segundos), pero el motor mira el reloj una vez por minuto, así que el intervalo más corto es de un minuto. El editor ofrece presets («Cada minuto», «Cada hora», «Laborables a las 08:00» y así sucesivamente) y un «Personalizada» campo que describe tu expresión con palabras.

• Al publicar se calcula la próxima hora a partir de "ahora". Si vuelves a publicar sin cambiar la expresión ni la zona, se mantiene la próxima hora.
• Un run arranca hasta alrededor de un minuto después de su hora. trigger_scheduledAt contiene la hora prevista; trigger_createdAt contiene cuándo se puso realmente en cola el run.
• Como máximo una ejecución por ocurrencia. Si la plataforma estuvo caída, obtienes una ejecución por la ocurrencia atrasada y después el reloj salta a la siguiente hora futura: las ocurrencias perdidas no se recuperan.
• Mientras un workflow está pausado, las ocurrencias pasan en silencio. Cambiar «Live» no ejecuta lo que te perdiste.
• Las plantillas que se ejecutan en una agenda usan Europe/Madrid, escrito en el trigger.

Úsalo cuando tu propio sistema deba iniciar un workflow. Es un POST a una dirección privada con un secreto. La página Webhooks entrantes tiene el contrato completo, incluida la parte que sorprende: el cuerpo se valida contra el tipo que declaras después de que Filmo ya haya respondido 202.

Úsalo para reaccionar a algo que ha ocurrido en Filmo o en una cuenta conectada. Elige el evento en la paleta (el grupo Filmo tiene un desplegable por cada tipo de registro; las cuentas conectadas tienen sus propias secciones). El catálogo es cerrado: solo existen los eventos que contiene. Para ver la lista completa y los campos que lleva cada uno, consulta el referencia de eventos.

Cada evento publica dos variables:

• trigger_event, el sobre: el nombre del evento, el tipo e id del registro, su nombre, el código de la acción, quién hizo el cambio (actor.kind es user, contact o system, con un id y un nombre) y de dónde vino (origin).
• trigger_<record>, una proyección del registro con solo los campos que lista el evento (un pedido tiene su número, estado, contacto, fechas, etc., pero no sus líneas ni su total). Para leer más, añade un paso que obtenga el registro.

origin indica cómo se hizo el cambio: Neo, Automation (hecho por un workflow), API, MCP o Integration. Un cambio hecho en la propia app no lleva origin, así que un filtro "origin is App" nunca puede coincidir.

Un trigger de evento puede llevar una condición, «Solo cuando», o, para los eventos de actualización que informan de qué cambió, «Solo cuando cambie» (algunos eventos de actualización sí pueden). La condición se evalúa cuando se recibe el evento, contra la versión publicada, antes de que exista ninguna ejecución.

• Es una sola comparación, sin y/o. El valor de la derecha es siempre un literal.
• Falla en cerrado: debe evaluarse exactamente a true. Una variable ausente o un null significan que no hay ejecución, sin avisar (salvo con "no es igual a": una variable ausente no es igual a nada, así que esa comparación es verdadera y deja pasar el evento). Un tipo que no coincide también significa que no hay ejecución.
• Un evento que no pasa el filtro no deja ninguna ejecución, ni siquiera una fallida. Si un workflow nunca se dispara, revisa primero el filtro; consulta la página de resolución de problemas.
• Comparar una fecha con un instante (2026-09-04 frente a 2026-09-04T00:00:00.000Z) nunca da igualdad, y "es posterior a" o "es anterior a" los comparan como texto, lo que puede coincidir por error. Compara cosas del mismo tipo.
• «Solo cuando cambie» mira lo que la acción emisora informa como cambiado; un guardado parcial que toca otros campos no informa de nada y, por tanto, no pasa.
• Un cambio en el filtro surte efecto cuando lo publicas, no cuando lo editas.

• Solo existen los eventos del catálogo. Varias cosas que parecen eventos no lo son: mover una unidad serializada por preparar, entregar o devolver, los cambios de stock a granel, el email entregado o abierto, las etiquetas, la disponibilidad y la mayoría de las importaciones no disparan un workflow.
• Algunos registros tienen un evento de eliminación (contactos, tareas, incidencias, artículos, presupuestos, facturas y otros, pero no pedidos, proyectos ni vehículos). Lleva solo la instantánea de lo que se eliminó, no el registro vivo.
• Las escrituras hechas mediante la API REST y MCP siguen la misma ruta que el mismo cambio en la app, así que disparan los mismos eventos, con origin establecido en API o MCP. Esto se cumple cuando la acción detrás del endpoint es uno de los eventos del catálogo; no se documenta endpoint por endpoint si la acción de cada uno lo es. Consulta qué pone en marcha una escritura por la API en la visión general.
• Un evento de cambio en Filmo se envía después de devolver la respuesta y no se reintenta si el envío falla. Los eventos de cuentas conectadas que fallan se reenvían.

Los eventos de cada origen se listan en la referencia de eventos, en las secciones enlazadas en la primera columna.

Un trigger de una cuenta que no está conectada se puede publicar y poner en Live, y simplemente nunca se disparará; Filmo no te lo impide.

La ejecución actúa como el creador del workflow, nunca como la persona que hizo el cambio, aunque el cambio lo haya hecho un cliente en el portal. Consulta Permisos.

Un trigger de señal escucha una señal con nombre que otro workflow lanza con datos. Las señales las definen los administradores en «Señales de workflows» y se describen en Señales y encadenamiento de workflows.

Cada trigger publica sus propias variables (trigger_…) y cada ejecución tiene además system_today. La página de referencia de cada trigger las lista: manual, desde un registro, desde otro workflow, programado, webhook, evento y señal. trigger_createdBy es siempre quien creó el workflow.

system_today es la fecha en que se puso en cola la ejecución, en la zona horaria de la empresa. Consulta Esperas y fechas.