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 step on the Deals object.
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.
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.1
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.
2
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.Choosing what agents can read
The 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.
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 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.1
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.
2
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.
3
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.