Reference

Viewer edits

A published view can let the people you share it with change records in your Attio workspace, one attribute at a time, either with your approval or without it. Editing is off on every new view, and turning it on takes four separate decisions.

What has to be true first

A viewer can change a cell only when all four of these hold. The viewer-edits section of Access shows them as a numbered checklist, ticked or not, with a button beside each one that is not done yet.

Your plan includes viewer edits. They are on Starter and Pro.
The view can tell who a viewer is. Every change is attributed to an email address, so the view needs email login (an email or domain allowlist) or row scoping. A password does not count, because it proves someone knows the password, not who they are.
At least one attribute is marked Editable. The Editable tick is on the view’s Columns page, beside each visible attribute. Only some attribute types can ever be editable; the attribute type support page has the split and the reason for each.
Editing is switched on for the view. Under Advanced on the Access step, or Expiry, downloads and viewer edits from the editor’s Access row.

You can do these in any order. Attributes ticked Editable before editing is switched on are stored and start working the moment the rest is in place, and the Columns page says so in a plain line rather than a warning.

Turning editing on changes who can read the view, not only who can edit it. Email login challenges every visitor. Once a view has an allowlist, everyone is asked for an address before they see a single row, including people who only came to read. There is no setting that asks for an address only from the people who want to edit. The confirmation step says this before you commit.

Three settings

Setting	What happens to a change	Who decides	The view needs
Read only	Nobody can change anything through the view.	Nothing	Any way in
With your approval	Each change waits on the Edits page until you approve or reject it.	You, before every write	Email login or row scoping
Without your approval	Each change is approved automatically and written to Attio within seconds.	Nobody first. Every change is still listed afterwards, with the value it replaced	Email login or row scoping, with verification forced on

A fourth option is listed and cannot be picked: changes written straight into Attio while the viewer waits. A published view never calls Attio itself, so a viewer can never wait on a write to your workspace. Changes without your approval are written by a background job a few seconds later instead, which gets you the same result without that call.

With your approval

The default once editing is on, and the one to start with. A viewer’s change is stored as a pending edit. Nothing reaches Attio until you approve it, and rejecting it throws it away and changes nothing.

This setting works with verification off, which means a viewer may have only typed a listed address rather than proved they own it. That is allowed because a person reads every change before it is written: the Edits page prints a typed address as typed … unverified, separately from a verified one, so you know which you are looking at. See email verification.

Without your approval

Each change is approved automatically and written to Attio within a few seconds. It is not a shortcut past any check: the change is validated exactly as an approved one would be, stored as the same kind of record, and listed on the Edits page with the value it replaced. The only thing it skips is you.

Verification is forced on. Choosing this setting switches on Make viewers verify their address by email and locks it. With nobody reviewing the change first, every change has to come from an address the viewer proved they own.
Switching back does not switch verification off. Going back to approval or to read only leaves verification on until you clear it yourself, so leaving this setting never quietly relaxes the gate.
Only the attributes you marked Editable can change, the same as with approval.

The confirmation for this setting spells out that you will not be asked first. Read it as the person whose CRM this is.

The Edits page

Open the view and use the editor’s Activity row, then Review edits. The Views list also carries a line when edits are waiting, with a link straight there.

Each change is a card with two columns: In Attio now, read from Attio when the page loads, and Proposed, what the viewer entered, with the difference marked. Under them is who made it: a verified address, or a typed one marked unverified. With approval, each card has Approve and write to Attio and Reject, and a bar above the list offers Approve all and Reject all for everything still waiting.

Anyone in the workspace can approve or reject, members included. Publishing and changing who can open a view stay with owners and admins, but deciding whether a viewer’s change is right is a judgement about the data, and whoever knows the record best is often a member.

State	What it means
Waiting for you	Proposed and not decided. Nothing has been written.
Approved, applying	Approved and on its way. The write happens in the background, a moment later.
Applied to Attio	Written. The card keeps the value it replaced.
Rejected	Thrown away. Nothing was written.
The value changed in Attio	Someone changed the attribute in Attio after the viewer saw it, so we wrote nothing.
Attio refused the write	Attio turned it down. Nothing was written.

The re-check before every write. Attio has no way to lock an attribute and no conditional write. So immediately before writing, we read that one attribute from Attio again and compare it with what the viewer was looking at. If it moved, we write nothing and mark the edit The value changed in Attio, and you see both values and decide again. That narrows the window to the few seconds between the check and the write. It does not close it: a change made in Attio inside those seconds can still be overwritten, and the page says so at the foot of the list.

Turning editing back to read only stops new changes. Anything already waiting can still be approved or rejected.

What the viewer sees

A cell the viewer can change looks like it: it shows a ring on hover and opens an editor when clicked or when the viewer presses Enter on it. A change is sent as soon as the viewer finishes it, by pressing Enter or clicking away. There is no separate Save step, and pressing Escape leaves the cell as it was.

Each changed cell carries a small mark whose words are in its hover text and its screen-reader label:

Sending, for the moment the change is on its way to us.
Waiting for approval, on a view that uses your approval.
Saved. Updating now, on a view without approval.

A change that was refused stays open in its cell, and a value in the wrong shape says what was wrong with it, so nothing a viewer typed disappears without them knowing. No mark ever says the record was updated, because the write happens a moment later and we will not claim your CRM changed before it has.

What editing cannot do

Change an attribute you did not mark Editable, or one the view does not show. An attribute has to be visible to be editable.
Create or delete records. A viewer changes values on records the view already publishes.
Touch a row the viewer cannot see. With row scoping on, a viewer can only change their own rows.
Undo itself. There is no revert button. Every applied change keeps the value it replaced, so you can put it back in Attio yourself.

Before you switch approval off

Run the view with approval for a while first. The Edits page shows you what your viewers actually change, and whether the addresses behind those changes are ones you recognise. Without approval, that page is where you find out afterwards instead.

Anything here wrong, or missing? support@publicviews.app.

All docs