> This page is for Platform Management.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.moveworks.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.moveworks.com/_mcp/server.

# Roles and Permissions

Tool Studio uses two permission axes: editing and runtime. The UI bundles common combinations into four roles, so you can grant access in one step.

This page covers the roles and the permissions behind them.

> **Per-asset roles are different from workspace roles**
>
> This page covers per-asset roles, which control access to individual assets and folders. Workspace roles, such as Tool Studio Admin and Tool Studio Developer, control org-wide Tool Studio access. The per-asset **Developer** role and the workspace **Tool Studio Developer** role are not the same thing. For workspace roles, see [Manage roles and permissions for Moveworks applications](/platform-management/access-control/manage-roles-and-permissions-for-moveworks-applications).

## The Four Roles

When you grant access to an asset or folder, choose one of four roles.

<table>
  <thead>
    <tr>
      <th>
        Role
      </th>

      <th>
        What it grants
      </th>

      <th>
        Typical use
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        **Manager**
      </td>

      <td>
        Full control: run, edit, and manage access
      </td>

      <td>
        The asset owner or a folder administrator
      </td>
    </tr>

    <tr>
      <td>
        **Developer**
      </td>

      <td>
        Build, edit, and test the asset
      </td>

      <td>
        An active builder working on the asset
      </td>
    </tr>

    <tr>
      <td>
        **Operator**
      </td>

      <td>
        Run and reference the asset, but not edit it
      </td>

      <td>
        A consumer who runs or depends on the asset without modifying it
      </td>
    </tr>

    <tr>
      <td>
        **Viewer**
      </td>

      <td>
        Read-only
      </td>

      <td>
        A read-only observer
      </td>
    </tr>
  </tbody>
</table>

![Asset access role picker listing Manager, Developer, Operator, and Viewer roles](/_fern-img/ba8d8ec68089d177ade5701e0a14b357c72a473095834ac9dafb7b95d1d12c43.webp)

## The Two Permission Axes

Each role maps to editing access, runtime access, or both.

### Editing Axis (Authorship)

The editing axis controls who can read and change an asset's configuration and logic. Each level includes the levels below it:

`View` \< `Edit` \< `Manage`

* **View**: see the asset's definition and metadata.
* **Edit**: modify the asset's configuration and logic, publish it, and move it between folders.
* **Manage**: everything in Edit, plus delete the asset and change who can access it.

### Runtime Axis (Execution)

The runtime axis is a single permission:

* **Use**: run the asset, test it, view its execution logs, and reference it from another asset.

`Use` controls both build-time selection and runtime execution. Without it, you cannot pick the asset in a dropdown, run it, or test anything that would execute it.

### Why the Axes Are Independent

Editing and runtime answer different questions. Having one does not imply the other.

For example, a developer can have `Edit` on a Workday HTTP action. They can read and change the action's logic, but they cannot run it unless they also have `Use` on the action and the underlying Workday connector.

Teams can let more developers build while limiting execution to the right people.

> **Use is developer execution, not end-user access**
>
> `Use` decides whether a *developer* can run or test an asset while building. It does not control which *employees* can use a published plugin. For that, use [End-User Access Control](/platform-management/access-control/end-user-access-control).

## How Roles Map to Axes

<table>
  <thead>
    <tr>
      <th>
        Role
      </th>

      <th>
        Editing
      </th>

      <th>
        Runtime
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        **Manager**
      </td>

      <td>
        Manage
      </td>

      <td>
        Use
      </td>
    </tr>

    <tr>
      <td>
        **Developer**
      </td>

      <td>
        Edit
      </td>

      <td>
        Use
      </td>
    </tr>

    <tr>
      <td>
        **Operator**
      </td>

      <td>
        View
      </td>

      <td>
        Use
      </td>
    </tr>

    <tr>
      <td>
        **Viewer**
      </td>

      <td>
        View
      </td>

      <td>
        None
      </td>
    </tr>
  </tbody>
</table>

## Permission Matrix

The table below shows what each role can do on a single asset.

<table>
  <thead>
    <tr>
      <th>
        Action
      </th>

      <th>
        Viewer
      </th>

      <th>
        Operator
      </th>

      <th>
        Developer
      </th>

      <th>
        Manager
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        View asset definition and metadata
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        See the asset name for reference
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Test or run the asset
      </td>

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Reference the asset in another asset
      </td>

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        View execution logs and analytics
      </td>

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Modify asset configuration and logic
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Publish the asset
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Launch a plugin to users
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Move the asset into a folder
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Export or import the asset
      </td>

      <td />

      <td />

      <td>
        ✅
      </td>

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Delete the asset
      </td>

      <td />

      <td />

      <td />

      <td>
        ✅
      </td>
    </tr>

    <tr>
      <td>
        Change the asset's access and sharing
      </td>

      <td />

      <td />

      <td />

      <td>
        ✅
      </td>
    </tr>
  </tbody>
</table>

> **Info**
>
> Logs and analytics follow the `Use` permission. If you can execute an asset, you can see its execution data. Every user also needs a workspace-level Tool Studio role before per-asset permissions apply.

## What a Manager Can Do That a Developer Can't

Both roles can edit, publish, run, and reference an asset. Only a **Manager** can govern the asset itself:

* **Delete** the asset.
* **Change its access and sharing.**

To grant someone access to an asset, you need Manager on that asset. An admin can also grant access.

## Related

#### [Folders](/platform-management/folders)

How folders set the default role for the assets inside them.

#### [Connectors and Access](/platform-management/access-control/connectors-and-access)

Why running an asset requires Use across its whole dependency chain.