Introducción
Cómo funcionan los workflows
Un workflow es una automatización que construyes en la app de Filmo. Un trigger lo inicia; los pasos que siguen hacen el trabajo, uno tras otro.
Las partes
Enlace a esta sección: Las partes| Término | Qué es |
|---|---|
| Workflow | Un trigger y los pasos que lo siguen, con un nombre, un estado y un creador. |
| Trigger | Lo que inicia el workflow. Cada workflow tiene exactamente uno. |
| Paso | Una unidad de trabajo: enviar un email, crear una tarea, llamar a una URL, esperar, decidir. Los pasos son atómicos, compuestos (contienen otros pasos) o una capacidad de Filmo. |
| Ejecutar | Una ejecución de un workflow, desde el momento en que se pone en cola hasta el momento en que termina. |
| Versión | Una copia congelada y numerada del workflow que publicaste. Los runs usan una versión, nunca el borrador que estás editando. |
| Borrador | Lo que ves en el editor. Se guarda mientras editas, pero no se ejecuta hasta que lo publicas. |
| Live | El interruptor que permite que los triggers automáticos (agenda, webhook, evento, señal) inicien ejecuciones. |
| Variable | Un valor que un paso o el trigger pasa a los pasos siguientes. Lo eliges de una lista; no hay sintaxis de fórmulas que escribir. |
| Señal | Un mensaje con nombre que un workflow lanza y que otros escuchan. |
| Plantilla | Un workflow ya hecho del que partes, con los huecos que aún tienes que rellenar. |
Del trigger a la ejecución terminada
Enlace a esta sección: Del trigger a la ejecución terminadaCuando se dispara un trigger, Filmo no ejecuta los pasos en ese momento. Pone en cola una ejecución que apunta a la versión publicada del workflow, y un worker la recoge poco después. Los pasos se ejecutan entonces estrictamente en orden; no hay ramas en paralelo.
Insertar una ejecución:
queuedUn botón, la API, una agenda, un webhook, un evento o una señal. El run apunta a la versión publicada del workflow, nunca al borrador.
Kick:
executeEl latido de cada minuto es la red de seguridad: un aviso perdido se recoge en el minuto siguiente.
El worker reclama la ejecución: estado
running, un lease de 300 segundosReproduce el diario y luego ejecuta los pasos. Cada unidad de trabajo se registra una vez; una ejecución reanudada reproduce lo que ya hizo en lugar de hacerlo de nuevo.
completed·failedTerminal. Un paso fallido termina la ejecución como fallida; no hay reintento automático de un paso.
waiting+ una hora de reanudaciónUn paso de espera, o un backoff de reintento tras un error del motor. El siguiente tick después de esa hora la devuelve a la cola.
pausedLa plataforma la detuvo antes de un paso: no queda crédito o hay un problema de pago. Solo Reanudar la devuelve a la vida.
Cada unidad de trabajo se registra al completarse. Ese registro permite que una ejecución se detenga a mitad, por una espera o un reintento, y continúe más tarde sin repetir lo que ya hizo.
Borrador, versión, Live
Enlace a esta sección: Borrador, versión, LiveEditar y publicar son cosas distintas. El editor guarda tus cambios mientras trabajas, pero solo se crea una versión cuando pulsas «Publicar». Cambiar «Live» activar o desactivar no crea una versión; solo decide si se disparan los triggers automáticos. Lee Versiones para ver los detalles, incluido lo que no puedes hacer (no hay historial de versiones ni restauración).
Editar el lienzo: guardado automático
Se guarda tras una breve pausa. Escribe solo el borrador y lo marca como «Cambios sin publicar». Lo que se ejecuta no cambia.
«Publicar»
Congela el borrador como una nueva versión numerada y reconstruye los triggers. Las ejecuciones nuevas la usan; las que ya están en curso conservan la suya.
«Live» activado: los triggers automáticos (programación, webhook, evento, señal) se disparan e inician ejecuciones de la versión publicada
«Descartar»
El borrador vuelve a la versión publicada. No hay forma de volver a una anterior.
«Ejecutar workflow»
Una ejecución manual usa la versión publicada. Si el borrador tiene cambios sin publicar, el editor los publica primero.
Como quién actúa una ejecución
Enlace a esta sección: Como quién actúa una ejecuciónUn run no actúa como la persona que hizo clic «Ejecutar workflow», o como propietario de una clave de API, o como la persona cuyo cambio lo disparó. Cada paso que usa una capacidad de Filmo se ejecuta con los permisos del creador del workflow, comprobado de nuevo en cada paso.
Cuánto cuesta
Enlace a esta sección: Cuánto cuestaUn run consume créditos: uno por cada paso de acción que se completa, más créditos extra por los pasos que llaman a la IA. Las condiciones, los bucles, los switches y los pasos fallidos son gratis. Consulta Límites y créditos.
Qué no son los workflows
Enlace a esta sección: Qué no son los workflows- Los pasos nunca se ejecutan en paralelo, y ningún paso tiene una opción "continuar si hay error": un paso que falla termina el run como fallido, salvo que lo pongas dentro de un paso Intentar, que deja que el run siga.
- Un paso que inicia otro workflow o lanza una señal no espera el resultado; el otro workflow es una ejecución propia.
Siguientes pasos
Enlace a esta sección: Siguientes pasosEmpieza con una plantilla, publícala y mira una ejecución.
Las siete formas de empezar un workflow, y las trampas de cada una.
Cómo lee un paso lo que produjo un paso anterior.
Estados, el visor de runs, cancelar, reintentar y reanudar.
Páginas relacionadas
Enlace a esta sección: Páginas relacionadasIntroducción
Inicio rápido: ejecutar un workflow desde una plantilla
En unos diez minutos crearás un workflow a partir de una plantilla, lo publicarás, lo ejecutarás una vez a mano y verás qué ha pasado, paso a paso.
Ejecutar
Versiones
Un workflow tiene un borrador que editas y una versión publicada que se ejecuta. Son distintos a propósito, y la forma en que difieren es de donde vienen la mayoría de las sorpresas.
Ejecutar
Permisos de workflows
Se mezclan dos preguntas: quién puede gestionar un workflow, y qué puede hacer un run. La primera trata de los administradores. La segunda, de una sola persona: el creador.
¿Te ha resultado útil esta página?