Permisos de workflows

Todo lo que cambia un workflow, o inicia una ejecución de él, requiere un rol de administrador: super-admin, admin, owner o el rol de soporte de Filmo. Eso incluye:

• Crear un workflow, también a partir de una plantilla.
• Editarlo. Incluso el guardado automático del borrador lo necesita.
• Publicar, pasarlo a Live o a Pausado, renombrar, cambiar su visibilidad o su aviso de fallo, archivar, restaurar y eliminar.
• Ejecutarlo a mano, desde un registro o mediante la API.
• Cancelar, reintentar y reanudar una ejecución.
• Crear y editar señales.

Cualquier miembro puede abrir el listado, el editor (para leer) y el historial de runs de un workflow que no sea privado, marcar favoritos y explorar la galería de plantillas.

Un workflow privado aparece en el listado para todos (con un candado), pero solo su creador y los administradores pueden abrirlo, editarlo y leer sus runs. Un workflow pasa a ser privado por sí solo cuando tiene un paso o un trigger de email o calendario; consulta Integraciones. Los administradores también pueden definirlo a mano con el «Privado» toggle.

Abrir un workflow público muestra su dirección de webhook y su secreto a la persona que lo abre.

• Los permisos se leen en cada paso, a partir del rol actual del creador (la consulta se guarda en caché hasta un minuto). No quedan congelados en la versión. Si más tarde el creador pierde rango o acceso, los pasos que necesitan lo que perdió empiezan a fallar.
• Un creador que ya no tiene acceso a la empresa no tiene ningún permiso: todos los pasos que necesitan uno fallan.
• Un paso rechazado falla con "You do not have permission to run <action>". El mensaje nombra la acción y, en el visor de runs, el paso fallido es el que hay que mirar.
• Las comprobaciones se aplican en este orden: si la acción llega próximamente, el add-on que necesita la acción, el permiso del creador, si el proveedor está conectado y los créditos de IA.
• La ejecución aparece en los feeds de actividad como "Workflow · <nombre del workflow>", con su origen como workflow, no bajo el nombre del creador.
• Si el creador deja la empresa, los pasos que necesitan un permiso fallan y los avisos de fallo van a los administradores.
• Desarrollo a medida es la excepción a quién configura un paso: solo el soporte de Filmo lo añade y lo edita. Cualquier otra persona que lo elija en la paleta recibe un diálogo para contactar con el equipo de Filmo y no se añade ningún paso. En un workflow, su configuración, entrada, salida y detalles de fallos solo los ve el personal de Filmo; si falla, el run dice únicamente que el desarrollo a medida no se pudo completar.

Once acciones de eliminar e invitar no comprueban el rol del creador, para que un workflow que limpia cosas siga funcionando cuando su autor cambia de rol. Siguen comprobando el plan, los add-ons, los proveedores y los créditos. Consulta Pasos.

El «Disparar workflow» paso exige que el creador sea administrador. Un workflow iniciado por un trigger programado o por un evento se encadena con la autoridad del creador, así que si el creador deja de ser administrador este paso se rompe, y lo descubres cuando se ejecuta.

Los pasos de email y de calendario usan los buzones del propio creador. Un compañero no puede enviar desde tu buzón a través de un workflow que hayas creado tú, y un workflow que hayas creado tú no puede tocar el de un compañero.

Una clave de API funciona con workflows solo si su propietario es un administrador activo, y necesita el scope workflows:read para listar y workflows:run para ejecutar. La ejecución en sí sigue actuando como el creador, no como el propietario de la clave. Consulta API y MCP.