Workflow Permissions

Overview

Workflow permissions control who can view, create, edit, and execute workflows in gaiia. Because workflows can automate actions at scale, permissions are restrictive by default to reduce the risk of unintended changes.

In this article, we’ll be covering how workflow permissions are structured and what each permission allows a user to do.

Understanding how workflow permissions are scoped

Workflow permissions are applied at two levels:

• Module-level permissions: which control access to workflows as a feature
• Object-level permissions: which apply to manually triggered workflows on specific objects

Object-level permissions apply to manual workflows triggered on Accounts, Commercial Accounts, Properties, and Units.

Managing module-level workflow permissions

Module-level permissions determine what actions a user can take within the Workflows module.

Edit

• Create new workflows
• Edit existing workflows
• Run one-off executions using the Test button

Execution

• Edit: cancel ongoing workflows and retry failed workflows.
• View: view workflow execution results, including inputs and outputs

Execution View access is required if Execution Edit is enabled.

Secrets

• Edit: create and update workflow secrets, such as passwords and API keys
• View: view workflow secrets without exposing sensitive values

Secrets View access is required if Secrets Edit is enabled.

Settings

• Edit: create and update workflow variables
• View: view existing workflow variables

Settings View access is required if Settings Edit is enabled.

View

• View workflow definitions and workflow metadata

View access is required if any other Workflow permission is selected.

Understanding permission inheritance

Workflow permissions use a parent-child inheritance model. When the parent Workflows permission is selected, all child permissions beneath it are automatically selected.

Child permissions cannot be enabled on their own and require the parent permission to be selected first.