Permissions and Run Identity
A workflow is a file, and its sharing settings decide what people can do with it. This page explains who can run a workflow, and whose permissions each part of a run uses.
Who can do what
| Action | Needs |
|---|---|
| Open the workflow, see its runs and logs | View access to the workflow |
| Run and Stop it | View access |
| Change its Schedule and triggers | View access |
| Retry a failed activity | Edit access, or being the user who started that run |
| Force run an activity | Edit access |
| Edit and save the workflow | Edit access (and Workflow Management) |
| Turn Run relational tasks as owner on or off | Being the workflow's owner, or a superuser |
Force run starts an activity straight away, ignoring the arrows and approvals before it, so it is limited to people who can edit the workflow.
Whose permissions a run uses
A run has an executing user:
- a manual run executes as the user who clicked Run;
- a scheduled run executes as the user who saved the schedule last (shown at the top of the Scheduler dialog);
- a blob storage or database trigger executes as the user who set the trigger up.
Activities run with the executing user's permissions: the files they can reach, the dimension members they can see, and the modules they have access to.
Assigned tasks (approvals, to-dos, data input, data loads) are different: the person they are assigned to does them, with their own permissions. When such a task opens a dashboard that has execute as owner set, that dashboard's queries use its owner's relational permissions, while dimension security stays the assignee's.
Relational tasks
When relational security is enforced, the workflow's relational tasks are checked against relational permissions before they touch the tenant database:
| Task | Needs |
|---|---|
| Stored procedure (on the AppDB data source) | Superuser or Relational Access |
| SQL bulk copy | Read access to the source table (its row filters apply) and unrestricted write access to the destination table |
| Remote data load, model query to a staging table, AI/ML.NET activities | The same table permissions on the staging tables they read and write |
| Data quality validation | Unrestricted read access to the staging tables it checks |
Staging tables managed by an integration cannot be written by these tasks. Tasks that use an external data source are not checked: the data source's own credentials decide what they can do.
If a task is denied, it ends in error and its log names the reason and whose permissions were checked. When the tenant runs relational security in log-only mode, the task goes ahead and the log records what would have been denied.
Run relational tasks as owner
A workflow that runs a stored procedure on the tenant database would fail for everyone who lacks Relational Access. To let other people run it, its owner can turn on Run relational tasks as owner in the Security panel of the workflow editor. Then:
- the relational tasks are checked against the owner's relational permissions, whoever starts or schedules the run;
- everything else still runs as the executing user, and assigned tasks still run as their assignee;
- the setting is captured when a run starts: turning it off, or a change of owner, only affects new runs. The run history shows the owner under Relational tasks as.
Only the owner or a superuser can change the setting. The owner is whoever saved the workflow last, so saving a workflow someone else owns while the setting is on asks you to confirm that you become the new owner; its relational tasks then run with your permissions.
When the setting is on and someone other than the owner starts a run, they can only fill in the workflow's declared
startup parameters, and the values may only contain letters, numbers, spaces and simple separators (. , : / % - [ ]).
If the owner leaves the tenant or is disabled, the relational tasks fail with a message saying so. The owner or a superuser can turn the setting off, or someone with Edit access can save the workflow to take it over.