Workflow permissions

Workflow permissions decide who can see, run, change and delete workflows and their runs. They are granted per workflow type: Lake, Warehouse and WriteBack. Use this page to give a colleague exactly the workflow access they need.

Set workflow permissions for a role

Click Admin in the sidebar, then Profile Management > Roles, and open the role you want to change. For how to edit a role, see Roles and permissions.
Click Permissions under Access.
Choose the Workflow Management category.
Tick the presets or single permissions you need.
Click Save changes.

Editing a role needs Roles Administrator, or the standard permissions it bundles, such as Edit Role Permissions.

Note

The built-in Admin role already holds every permission. Its permissions show as all granted and locked, and cannot be changed here.

Choose presets or single permissions

The permission editor groups permissions into High-Level, Standard and Granular sections. A high-level preset contains standard presets, and a standard preset contains granular permissions.

Preset	Section	What it grants
Workflow Administrator	High-Level	Full administrative access to all workflows
Workflow Viewer	High-Level	View all workflow types
Workflow Executor	High-Level	Execute and abort workflows

Each type has three standard presets. For Lake they are Lake Workflow Administrator (all five permissions), Execute/Abort Lake Workflows (View and Execute) and Lake Workflow Viewer (View alone). Warehouse and WriteBack have the same three, under their type names.

The granular permissions are the same five for each type. Lake is shown here:

Permission	What it lets a person do
View Lake Workflow Objects	See Lake workflows, their runs, nodes and diagrams
Execute Lake Workflow Objects	Run, restart and stop Lake workflows and their runs
Add Lake Workflows	Create Lake workflows
Modify Lake Workflows	Edit workflows and turn their schedules On or Off
Remove Lake Workflows	Delete workflows, and delete Failed or Aborted runs

Execute/Abort Lake Workflows includes View and Execute. A colleague who only watches runs and restarts failed ones needs that preset, not the viewer preset.

What each action needs

To	You need
See the Workflows item in the sidebar	View, for at least one type
Open workflows, runs and steps, and use the filters	View, for that type
Export the runs	At least one of the three View permissions
Run, restart or stop	Execute, for that type
Create a workflow	Add, for that type
Edit a workflow, or turn its schedule On or Off	Modify, for that type
Delete a workflow, or delete a Failed or Aborted run	Remove, for that type
Open the WF diagram of a Warehouse run	View Warehouse Objects, or Add/Modify Warehouse Objects
Move transformations to another workflow in a Warehouse diagram	Add/Modify Warehouse Objects

The two Warehouse Objects permissions sit in the Data Layer category, not in Workflow Management, so Workflow Administrator does not include them. The WF diagram of a Lake or WriteBack run needs only the View permission for that type. See Workflow diagram.

Without the permission, a control is hidden or greyed out. On a workflow card, Edit shows as View when the person can only read. In a run's menu, Restart, Stop and Delete stay greyed out when the person's permissions or the run's status do not allow them. Clicking Delete on a run without Remove shows a Cannot delete message instead of the confirmation dialog. See Job runs.

Scope: one type at a time

A permission for one workflow type never gives access to another type.

The Workflows item in the sidebar appears when a person holds View for at least one type.
The Lake, Warehouse and WriteBack chips show the types the person can view, and workflows of other types are left out of the list. See The Workflows screen.
Runs and steps of a type the person cannot view are not listed, and a direct request for one is refused.
The screen loads up to 5,000 workflows.

Failure alerts

The bell on a workflow card appears to people with an Add permission for any workflow type.
Listing the channels in the alerts window needs View Notifications or Modify Notifications.
Saving added channels and changed email recipients needs a Modify permission for any type.
Unticking a channel, or removing every alert, needs a Remove permission for any type.
The Execution tab of the alerts window needs View Notification Logs.

See Failure alerts for how alerts work, and Notifications for setting up channels.

Limits and edge cases

The Lake Administrator and Warehouse Administrator presets in the Data Layer category also include view, execute and modify for that type's workflows, but not add or remove. A role with one of them can run and edit those workflows without any Workflow Management permission. See Who can do what in the Lake and Warehouse permissions and row-level security.
The Warehouse's own workflow, DWH_Workflow, has no Delete action, whatever permissions you hold.
A run in Running or Running Error status cannot be deleted, whatever permissions you hold. Stop it first.
When the server refuses an action, the message starts with Access denied. Required permission(s): followed by the permissions that would allow it, using the names shown in the permission editor. When any one of several is enough, the names are joined with OR. A refusal scoped to one object names it, for example Access denied. You do not have permission to read this CoreTable when a Warehouse run's diagram is opened without Warehouse object access.
A saved change applies on the server straight away, and an open Workflows screen picks it up within about half a minute.

Questions, answered

How do I give someone just enough access to watch runs and restart failed ones?

Give them the Execute/Abort preset for the workflow's type: Execute/Abort Lake Workflows, Execute/Abort Warehouse Workflows or Execute/Abort WriteBack Workflows. It includes View and Execute, which is what restarting needs.

Why does a colleague see the Workflows item but no Warehouse workflows?

They hold no View permission for Warehouse. The list shows only the types the person can view, and Lake and WriteBack permissions do not show Warehouse workflows. Grant View Warehouse Workflow Objects, or the Warehouse Workflow Viewer preset.

Why are some runs or steps missing for a colleague?

Runs and steps of a type the person cannot view are left out, and a direct request for one is refused. Grant the matching View permission, such as View WriteBack Workflow Objects.

Does Add let a person run the workflow they create?

No. Running needs Execute for the type, or the Execute/Abort preset. Creating and running are separate permissions.

Why does a workflow card show View instead of Edit?

The person can view the workflow but not change it: they lack the Modify permission for that type. Grant Modify Lake Workflows, Modify Warehouse Workflows or Modify WriteBack Workflows.

Why is there no Delete action on the Warehouse's workflow?

The Warehouse's own workflow, DWH_Workflow, cannot be removed. Its card and tab menu show no Delete action, whatever permissions you hold.

Why does the alert bell not show for a viewer?

The bell shows only to users with an Add permission for some workflow type, such as Add Lake Workflows, and it stays disabled until a notification channel exists under Admin > Notifications. A viewer holds View permissions only. See Failure alerts.

Can someone who can only view export the runs?

Yes. A View permission for any one of the three types is enough to read runs, filters and export. The export saves only the runs the person can see.

Can I give access to one workflow instead of the whole type?

No. The workflow permissions are granted per type: Lake, Warehouse or WriteBack. A grant covers the type's workflows; a single workflow cannot be granted on its own.

Why has a permission change not taken effect yet?

It applies on the server straight away. An open Workflows screen picks it up within about half a minute. A person whose access is revoked, or whose session ends, is disconnected from live updates and must sign in again.