Agentic Workflow Permissions

Agentic Workflow permissions operate at multiple levels. One set controls who can access and configure an Agentic Workflow. A separate set governs who can view execution history and intervene in running executions. A third governs what the Agentic Workflow itself can do when it runs, and it is the level most critical to understand before deploying Agentic Workflows in any multi-user environment.

At runtime, an Agentic Workflow does not run under the permissions of the user who configured it or the user who triggered it. It runs with elevated platform access that bypasses standard permission checks.

Management access to Agentic Workflows — including the ability to create, edit, and delete them — is controlled at the permission group level. Enabling the Agentic Workflows toggle unlocks additional permission controls, each governing a different type of access.

To find all Agentic Workflow Permissions, do the following steps.

The Add Permission Group modal will pop up. and you'll need to scroll down to find the Agentic Workflow permissions, which you can toggle on. Each one is defined below for Agentic Worfklows, Single Record Actions, Bulk Actions, and Scheduled Agentic Workflows.

Manage Agentic Workflows controls whether members of a permission group can create, edit, and delete Agentic Workflows. This is the foundational permission for Agentic Workflow configuration access. Members without this permission cannot open, modify, or delete any Agentic Workflow in the workspace, regardless of what other Agentic Workflow permissions they hold.

The Modify Agentic Workflow control under Perform Single Record Actions governs whether a user can manually interact with an Agentic Workflow on an individual Record; for example, starting, pausing, or canceling an execution from a v view. This is configured per Object (including Contact, as seen below).

A separate Modify Agentic Workflow control under Perform Bulk Actions governs whether a user can apply Agentic Workflow actions across multiple Records at once. This is configured per Object (including Contact, as seen below).

Under Broadcasts in the Permissions settings, the Scheduled Agentic Workflows control governs access to scheduled Agentic Workflow configurations. This control uses four permission levels — None, View, Create/Edit, and Delete/All — and is configured separately from the Record-level action controls above.

Execution visibility controls who can see the execution history and step-level detail for a running or completed Agentic Workflow. Users with Record-level access but without Manage Agentic Workflows permission can see which Agentic Workflows ran against a Record and their status, but cannot open execution history or view step-level detail. Sensitive data processed during execution — such as Contact information, financial Records, or communications — is only exposed to users who have been granted full execution visibility.

Manually starting, pausing, or canceling an Agentic Workflow execution on a Record requires two conditions to be met simultaneously: the Modify Agentic Workflows permission and Edit access to the specific Record the execution is running on. The permission controls whether a user can interact with Agentic Workflow executions at all, while Record Edit access determines whether they can act on a particular Record. A user who has the permission but lacks Edit access to a Record cannot intervene in executions on that Record, and a user with Edit access but without the permission has no manual intervention controls available regardless of their Record access.

When an Agentic Workflow executes, it does not run under the permissions of any user. The permissions of the user who configured it, the user who triggered it, and any other user do not apply at runtime. This is intentional behavior. Agentic Workflows are designed to perform consistent, reliable operations regardless of who initiates them, so that execution outcomes do not vary based on the triggering user's permission level.

In practice, this means an Agentic Workflow can read fields, update Records, create Records, and send communications that the triggering user might not be permitted to perform manually. A user with restricted permissions who triggers an Agentic Workflow does not limit what that Agentic Workflow does.

Administrators should treat Agentic Workflow configuration as a governance responsibility. Recommended practices include:

Now that you understand how permissions govern access to Agentic Workflows and executions, the next topic covers what happens during an Agentic Workflow's operational life. Agentic Workflow Status & Lifecycle covers the statuses an Agentic Workflow and its executions move through, how those states transition, and how administrators can interpret the status indicators and error signals the platform provides.