Users can be restricted to what Apps they have access to using the policies and app restrictions. Besides that, in order to interact with automation, there are several permissions for read and write access, as well as a separate permission to run workflows. Those define access to those functions for users in general.
automation:workflows:read - Read access to workflows.
automation:workflows:run - Execute permissions for workflows.
automation:workflows:write - Write access to workflows.
automation:calendars:read - Read access to business calendars.
automation:calendars:write - Write access to business calendars.
automation:rules:read - Read access to scheduling rules.
automation:rules:write - Write access to scheduling rules.
Furthermore, all workflows have an owner. By default, the creator of a workflow is set as the owner with the visibility of the workflow as private. The owner can transfer ownership to another user. The owner can also change the visibility between private and public. The public makes the workflow visible to all other, workflow-enabled users in the same environment. Given the corresponding permissions are applied, users can then read, write and run those workflows. Changing visibility and ownership can only be done by the owner, even if the workflow is public (similar concept to credentials in the Dynatrace credential vault).
Each workflow has an “Actor” defined, which is set to the creator by default. All actions done by the workflow are done via this actor, which can be either a user or a technical user (no login allowed). Users must allow being impersonated by the automation service before any action can be run using that user as an actor. Furthermore, the user can specify the scope of the permission the automation service is allowed as that user during execution (workflow app – settings – authorization settings). Any action executed via the workflow is limited by both this scope as well as the user permissions.
As to what actions are available to be used in a workflow definition and executed: Actions are provided and managed via apps. The apps containing wanted actions need to be installed in the environment first before they are available for workflows.
There are two permissions to manage access to apps and therefore action as well as ad-hoc scripts.
app-engine:apps:run – Access to Apps (and its actions)
app-engine:functions:run – Ability to run custom ad-hoc scripts
app-engine:apps:run can be filtered using the WHERE clause and shared:app.id, to include / exclude certain apps. Apps and their actions are only visible to users who have this permission.
Michael
