Skip to content

Flow Permissions

A Flow follows the datastores it relates to. Viewing Flows and executions is open to every user role. Changing a Flow (creating, editing, publishing, activating or deactivating, executing, aborting or deleting its executions, or deleting it) needs the Editor team permission on every datastore the Flow relates to. This applies to Members and Managers alike. Admins can manage every Flow.

A Flow relates to a datastore when the datastore appears in its configuration:

Source Related Datastores
Trigger The datastores picked in the trigger's Datastores filter. With is not any of, every other datastore.
Operation actions The datastore each Sync, Profile, Scan, Export, or Materialize action runs on.
Anomaly actions The datastores picked in the action's datastore filter.
Global Export actions The enrichment datastore the export writes into.

Notification, ticketing, and workflow actions don't add related datastores.

Flows That Reach Every Datastore

Leaving a datastore filter empty doesn't mean the Flow relates to no datastore. It means the Flow acts on all of them:

  • An Operation Completed, Anomalous Table or File Detected, Anomaly Detected, or Anomaly Status Changed trigger with no Datastores fires on events from every datastore. So does one whose Datastores filter uses is not any of, since it reaches every datastore it does not exclude, including datastores added later.
  • An anomaly action with no datastore filter archives or deletes anomalies on every datastore.

Managing such a Flow needs the Editor team permission on every datastore in the deployment, enrichment datastores included. Wherever the Flow's related datastores are shown, they read All.

A Schedule or Manual Flow whose actions only notify or call a workflow relates to no datastore, so it reads and changes no data. Any Member or Manager can manage it, whatever their teams.

User Roles

Action Member Manager Admin
View Flows and their configuration
View executions and their details
Create and publish a Flow 1
Edit and publish changes to a Flow 1
Activate or deactivate a Flow 1
Execute a Flow 1
Abort or delete an execution 1
Delete a Flow 1
Create, edit, delete, or execute a Flow with a Global Export of check templates
Create, edit, delete, or execute a Flow with a Global Export of the Access Report

Global Export actions are gated by role

A Global Export action writes organization-wide data, so its rule depends on what it exports, on top of the team permission on its enrichment datastore. Exporting Check Templates needs the Manager or Admin role. Exporting Access Report needs the Admin role, and a Flow that contains one can only be created, edited, activated or deactivated, deleted, or manually executed by an Admin. The check happens when a person acts on the Flow, so once an Admin publishes it, the Flow still runs on its trigger (for example, its schedule) without anyone present.

Changing the related datastores changes who can edit

Publishing a change to a Flow's datastores also changes who can manage it from then on. A Flow that starts reaching every datastore can only be edited by Admins and by users with the Editor team permission on every datastore.

UI Behavior

Scenario What the User Sees
A Member or Manager opens the Flows page The Add Flow button is shown.
A Member or Manager picks a datastore in the Flow editor Every datastore input, in the trigger and in the actions, lists only the datastores the user holds the Editor team permission on. Admins see every datastore.
A Member or Manager configures an event trigger or an anomaly action The datastore filter is required, and the trigger's Save stays disabled until a datastore is picked, so the Flow can't be saved reaching every datastore. Admins, and users with the Editor team permission on every datastore, can leave it empty.
A user opens a Flow they can manage The side panel shows You can edit, and the canvas offers its editing controls.
A user opens a Flow they cannot manage The side panel shows Read only, the row's options menu is hidden on the Flows list, and the canvas offers no editing controls. This includes a Manager opening a Flow that contains a Global Export of the Access Report.
A user opens Related datastores in the Flow editor Each related datastore shows a pencil when the user edits it or an eye when it is read only for them, and the footer states what managing the Flow requires.
A user cannot manage an execution The row's Abort and Delete buttons are hidden, and bulk selection explains that the user doesn't have permission to manage the execution.

See Also

  • How It Works

    The canvas, Flow settings, chaining rules, and the publish lifecycle behind every edit.

    How It Works

  • Triggers

    The six trigger types, schedule configuration, and the filter conditions each type supports.

    Triggers

  • Actions

    The five action categories, the chaining rules between them, and where each is documented.

    Actions

  • Executions

    The Definitions and Executions tabs, execution states, and the read-only execution graph.

    Executions

  • Examples

    Real scenarios showing how a trigger and a chain of actions combine into a working automation.

    Examples

  • Best Practices

    Guidelines for building Flows that stay quiet when healthy and loud when something breaks.

    Best Practices

  1. Members and Managers need the Editor team permission on every datastore the Flow relates to, or on every datastore when the Flow reaches all of them. A Flow with no related datastore needs no team permission. Admins are not subject to team permissions. ↩↩↩↩↩↩