> ## Documentation Index
> Fetch the complete documentation index at: https://80x.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions & workflow access

> Three separate permission systems decide whether a workflow can run. They cover its data access, who can edit it, and what its agents may read.

Three separate permission systems decide whether a workflow can run. They cover its data access, who can edit it, and what its agents may read. The first controls what data the workflow itself can read and write. The second controls which people can see and edit the workflow. The third controls what any AI agent inside the workflow is allowed to touch. One error message rarely tells you which system is the problem. So a confusing failure stays confusing until you know which model to check.

When you confuse these three models, you waste debugging time on automations that touch live revenue data. Here is what that looks like in practice. A workflow that reads a deal perfectly can still fail to update it. A teammate who built a workflow can suddenly find it invisible to a colleague. An [agent](/reference/agents/custom-agent) can return empty answers about records it should obviously know. (An agent is an AI helper that runs inside a workflow.) Each symptom maps to exactly one of the three models.

This page explains each model in the order you meet it when a workflow breaks. It gives you a small example of the most common failure for each one. It ends with a triage routine that turns the error text into the right fix. After reading it, you can do three things. You can grant a workflow the narrowest access it needs. You can share a workflow without accidentally exposing production deploy rights. You can decide whether an agent should run as the workflow or as a person.

## Granting the workflow's own data access

A workflow can read objects freely, but it has no write access to them by default. This is the model behind the most common permission error, so check it first. A workflow that reads a deal without trouble can still fail the moment it tries to update that deal. It returns the error *"This workflow does not have permission to write for this object."*

The fix is to grant write access on purpose, one object at a time. Do not hand the workflow broad access across the whole workspace. An admin makes the grant in the object's access settings. Any member with full access to the object can make it too. This small grant resolves a failing [Update record](/reference/records/update-record) step on the Deals object.

| Field | Value |
| - | - |
| Object | Deals |
| Granted to | This workflow |
| Access level | Read and write |
| Granted by | An admin or a member with full access to Deals |

After this grant, the workflow's `Update record` step writes to Deals on its next run. It no longer returns the write-permission error.

Grant write access narrowly. A workflow has both broad write access and the ability to act at automation speed. A wiring mistake in a workflow that can write to every object can corrupt many records before anyone notices. So treat each granted object as a deliberate decision, not a default.

## Writing across relationship attributes

A relationship attribute links two objects, such as a deal and its company. Writing to one needs write access on both sides of the link, not just the object you think you are editing. Updating a "Deals ↔ Companies" relationship needs write access on Deals *and* on Companies. The workflow touches a record on each side. This is the same permission model as the previous section, but it produces a nastier symptom.

The trap is that a half-granted relationship fails some of the time, not every time. A run that only needs to read the linked Companies record succeeds. A run that needs to update it fails with the same write-permission error. So the workflow looks healthy until a specific input path hits the missing grant. This complete grant covers a step that links a deal to its company.

| Field | Value |
| - | - |
| Attribute being written | Associated company (Deals ↔ Companies) |
| Write access needed on | Deals and Companies |
| Common mistake | Granting write on Deals only |
| Resulting symptom | Intermittent write-permission errors on some runs |

After you grant write on both objects, the relationship update succeeds on every run. Before, it only worked on the runs that avoided the ungranted side.

## Sharing the workflow with people

Workflow sharing controls which people can see and edit the workflow. It is a separate system from data access. The **Share** button exposes four levels: **Full access** (edit plus manage access), **Read and write** (edit plus publish), **Read only**, and **No access**. Managing access requires a paid plan. Team-level and member-level grants are available on Pro and Enterprise.

One rule surprises people. A more specific setting can only grant *additional* access. It can never reduce access. Say the workspace-wide level is **Full access**. An individual **No access** assignment on one member does nothing, because the broad grant already covers that person. So the only way to restrict anyone is to set the floor low and raise specific people up.

<Steps>
  <Step title="Set the workspace floor to the lowest sensible level">
    Set workspace-wide access to the lowest level anyone should have, which is often **Read only**.
  </Step>

  <Step title="Raise specific maintainers past the floor">
    Grant **Full access** or **Read and write** to the named people who maintain automations, such as `jane@acme.com` on your RevOps team.
  </Step>
</Steps>

After this configuration, only your named maintainers can edit the workflow. Everyone else inherits the read-only floor.

Treat edit rights on a workflow the way you treat production deploy rights. Anyone with edit access can change a live revenue automation. The same caution that governs who can ship code to production should govern who can publish a workflow that moves deals or sends customer-facing messages. The page on [Runs, debugging & publishing](/explanation/runs-and-debugging) covers what publishing actually changes.

## Choosing what agents can read

The [Custom agent](/reference/agents/custom-agent) block adds a third model on top of the first two. It is called **Run as**. An agent's tool access is read-only, so this model decides whose readable data the agent sees. It does not decide whether the agent can write. The choice is between running the agent as the workflow or running it as a specific workspace member.

Running as the workflow is the narrower option and the right default. The agent reads workspace-visible data such as notes and call recordings. It also reads whatever objects and lists the workflow itself can read under the first model. Running as a workspace member is wider. The agent then reads *everything that member can access*. That makes it suitable only for genuinely personal tasks, such as a digest of one person's own meetings. This table contrasts the two settings for an agent that summarizes account activity.

| Setting | Reads | Use when | Cost of choosing it |
| - | - | - | - |
| Run as the workflow | Workspace-visible data plus the workflow's readable objects | The task is account-wide, not personal | Narrowest access; nothing breaks at offboarding |
| Run as a workspace member | Everything that member, such as Priya Sharma, can access | The task is genuinely personal, like a digest of her own meetings | Offboarding Priya later breaks the workflow |

After you choose **Run as the workflow**, the agent answers from shared data. It keeps working even when an individual member leaves the workspace.

Running as a member adds two requirements before the agent works. First, the member must explicitly approve the request through **Share access** in their Ask Attio settings. Second, they must connect their own apps. The agent can then use their Model Context Protocol (MCP) tools. MCP is the standard that lets an agent reach a person's connected apps. Until both steps happen, an agent set to run as that member returns empty answers. It appears to have access, but it does not. That is the third model's signature failure.

Enable web access on an agent only when the task genuinely needs the web. Once you do, external page content can influence the agent's behavior. The [Web agent](/reference/agents/web-agent) block exists for tasks that require browsing. Keeping web access off elsewhere narrows the surface that outside content can affect.

## Triaging a permission error

The three models share overlapping error text. So the fastest path is to read the symptom, not the message. Each of the three common symptoms maps to exactly one model and one fix.

<Steps>
  <Step title="The error mentions permission to write">
    This is the data-access model. Have an admin grant the workflow write access to the object. Check both sides of any relationship attribute involved, since a half-granted relationship fails only on some runs.
  </Step>

  <Step title="A teammate cannot see or edit the workflow">
    This is the sharing model. Check the **Share** settings. Remember that access only escalates from the workspace floor, so a low floor plus an explicit grant is the only way to restrict anyone.
  </Step>

  <Step title="An agent returns empty answers it should know">
    This is the agent model. Check the agent's tool access list. Confirm that its **Run as** member ever approved the access request and connected the needed apps.
  </Step>
</Steps>

After you match the symptom to its model, you change exactly one setting. You no longer guess across three systems.

*Sources: Attio Help Center, [Manage access to objects](https://attio.com/help/reference/managing-your-data/objects/manage-access-to-objects). Last reviewed against the Attio Help Center, June 2026.*

## See also

* [Custom agent](/reference/agents/custom-agent)
* [Web agent](/reference/agents/web-agent)
* [Runs, debugging & publishing](/explanation/runs-and-debugging)
* [Workflow governance](/explanation/workflow-governance)
* [Manage access to objects](https://attio.com/help/reference/managing-your-data/objects/manage-access-to-objects)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.