*Workflows › Run* # Workflow permissions > Two questions get mixed up: who may manage a workflow, and what a run is allowed to do. The first is about administrators. The second is about one person: the creator. ## Who manages workflows Everything that changes a workflow, or starts a run of it, needs an administrator role: super-admin, admin, owner or the Filmo support role. That includes: - Creating a workflow, including from a template. - Editing it. Even the autosave of the draft needs it. - Publishing, switching it live or paused, renaming, changing its visibility or its failure notice, archiving, restoring and deleting. - Running it by hand, from a record or through the API. - Cancelling, retrying and resuming a run. - Creating and editing signals. Any member can open the list, the editor (to read) and the run history of a workflow that is not private, mark favourites, and browse the template gallery. > **A member who is not an administrator loses their edits:** The interface does not hide the controls that need an administrator. A member who is not one can see the buttons, and each action is refused with a message, except the autosave of the draft: its refusal is silent, so their edits are never saved and are lost when they reload. ## Private workflows A private workflow is listed to everyone (with a padlock) but can be opened, edited and have its runs read only by its creator and by administrators. A workflow becomes private on its own when it has an email or calendar step or trigger; see [Integrations](https://docs.filmo.io/workflows/integrations#mailbox). Administrators can also set it by hand with the «Private» toggle. Opening a public workflow shows its webhook address and secret to the person opening it. ## What a run acts as > **The creator:** A capability step runs with the permissions of the creator of the workflow, in every run, whatever started it: a person's button, a schedule, a webhook, an event, a signal, another workflow or the API. It is not the person who pressed Run, not the owner of the API key and not the person whose change fired the event. - The permissions are read at each step, from the creator's current role (the lookup is cached for up to a minute). They are not frozen in the version. If the creator is later demoted or loses access, the steps that need what they lost start to fail. - A creator who no longer has access to the company has no permissions at all: every step that needs one fails. - A refused step fails with "You do not have permission to run ". The message names the action and, in the run viewer, the failed step is the one to look at. - Gates apply in this order: whether the action is coming soon, the add-on the action needs, the creator's permission, whether the provider is connected, and the AI credits. - The run is shown in activity feeds as "Workflow · ", with its origin as workflow, not under the creator's name. - If the creator leaves the company, the steps that need a permission fail, and the failure notices go to the administrators. - Custom development is the exception to who configures a step: only Filmo support adds and edits it. Anyone else who picks it in the palette gets a dialog to contact the Filmo team and no step is added. In a workflow its configuration, input, output and failure details are visible to Filmo staff only; if it fails, the run says only that the custom development could not be completed. ### Steps that do not depend on role Eleven delete and invite actions do not check the creator's role, so that a workflow that cleans things up keeps working when its author changes role. They still check the plan, add-ons, providers and credits. See [Steps](https://docs.filmo.io/workflows/steps#system-actions). ### Chaining The «Trigger workflow» step needs the creator to be an administrator. A workflow started by a schedule or an event chains with the creator's authority, so a creator who stops being an administrator breaks that step, and you find out when it runs. ## Email and calendar The email and calendar steps use the creator's own mailboxes. A colleague cannot send from your mailbox through a workflow you made, and a workflow you made cannot touch a colleague's. ## The API and MCP An API key works with workflows only if its owner is an active administrator, and it needs the scope `workflows:read` to list and `workflows:run` to run. The run itself still acts as the creator, not as the key's owner. See [API and MCP](https://docs.filmo.io/workflows/api-and-mcp). --- Canonical URL: https://docs.filmo.io/workflows/permissions Last updated: 2026-10-09