Reference
Running a live view
A published view keeps reading Attio on a schedule, keeps a record of who opened it, and can be taken down in one click. This page covers all three, and the few cases where the product takes a view down for you.
How current a view is
We keep a copy of the records behind a published view and serve viewers from it, rather than calling Attio every time someone opens the link. That is why traffic on a view never costs you any of your Attio rate limit, and it is also why a view is as current as our last check rather than as current as Attio.
On a paid plan we check Attio every 5 minutes up to 500 records, every 15 minutes up to 5,000, and hourly up to 50,000. Free views check every hour. A paid view above 500 records also gets a check for newly created records every 5 minutes. A smaller one does not need one, because its full check is already that often. Nothing else moves faster: a record that changes into the view, or out of it, waits for the next full check. A source that matches more than 50,000 records is checked every six hours, on either plan.
Every published view shows its viewers when it last updated, and leaves the time out rather than guess when it does not know.
Syncing now
The data and sync screen is where a view’s records come from. The editor’s Rows row links to it (Change which records this publishes). It holds the filter, the Sync history of every read, and a Sync now button that queues a read from Attio ahead of the schedule. Pressing it only queues the read; the view picks up the result when the read finishes, and the card updates itself when it does. Straight after a sync, the next on-demand one is held for a moment and the card says when it can start.
Sync now is not offered as a fix when something else is wrong. If the Attio connection needs reconnecting, Attio is rejecting the filter, or syncing is paused, the button says which, and points at the thing that actually needs doing.
Analytics
From the editor’s Activity row, Open analytics. The page covers the last 14 days.
- Four counts, on every plan: visits, unique viewers, edits proposed, and visitors denied at the gate, each with its trend. They are totals and carry no viewer identity.
- The access log, on Pro: every open, denial, edit and download, by viewer, with the address they used and how they got in, and an Export CSV button that downloads the same rows the table shows.
The access log is recorded on every plan. Only reading it back is limited, so moving up shows you the history you already have.
How much history is kept depends on the plan. After a downgrade, anything older than the new plan’s history stops being shown.
| Plan | Analytics history |
|---|---|
| Free | 30 days |
| Starter | 365 days |
| Pro | 730 days |
Pause, publish again, delete
| What happens | What survives | Coming back | |
|---|---|---|---|
| Pause | The link stops working immediately and every open viewer session is signed out. | Everything. The address, the settings, the history. | Publish again, from the same place |
| Paused by us | The same as a pause, done by the product for one of the reasons below. | Everything. | Fix or accept the reason, then Publish again |
| Delete | The link stops working and its address is retired for good. | Nothing. Settings, edits, the access log and analytics go with it. | No. Publishing the records again gives a new address |
Pause is in the header of every page of a live view and on its row in the Views list. It is one click with no confirmation, because pausing is always the safe direction, and it tells you how many open viewer sessions it signed out. A viewer who opens the link while it is paused is told it is paused and that their link will work again, and nothing about the data.
Publish again is the one with a dialog. It runs the same checks a first publish runs, so if the filter, the connection or your plan changed while the view was paused, it stays paused and the dialog says why. The view comes back at its old address, and every link that worked before works again.
Delete view is beside Pause in the editor’s header, and opens a page of its own. It lists what will be destroyed, counted at that moment, and asks you to type the view’s name. The address is retired permanently, because a link is a key and we never hand the same one to a different view. Your Attio data is untouched; we only ever held a copy. If you only want the view offline, pause it.
Paused by us
A view the product paused carries Paused by us instead of Paused, on the Views list and in the view’s header. It happens for a small number of reasons, all of them cases where carrying on would publish more than you agreed to.
- The records behind it grew sharply. Each sync compares how many records the filter now matches with the number you last confirmed (when you published, or when you last saved the filter). A sharp jump in that number pauses every view over those records before the new ones are shown. A filter that suddenly matches ten times as many records is publishing ten times as much of your CRM to a link that is already out there, and a pause costs you one click.
- Your plan changed. After a downgrade, views over the new plan’s limit are paused, never deleted. A view that shows each viewer only their own rows is paused rather than shown to everyone unscoped, if the new plan does not include row scoping.
To bring a view back after a jump, open its data and sync screen. It shows the new count against the old one and offers Accept N records and resume, which makes the new count the one future syncs are compared with. Then publish the view again.
What never pauses a view: records dropping out, renamed attributes, new attributes, ordinary day-to-day churn, or a single sync that fails. Pausing on those would teach you to click through pause notices without reading them, which would defeat the one that matters.
An Attio saved view that turns out to be the whole list
Attio’s API does not tell us what a saved view filters on, so the first sync measures it. If the saved view returns every record in the list, syncing is paused before anyone can open the view, and nothing is published. The data and sync screen explains, and offers to publish every record anyway if that is what you meant, or you can pick a narrower saved view. The same screen tells you if the saved view is later deleted or renamed in Attio.
The emails we send you
They go to the workspace’s owners and admins.
- A view was paused. Straight away, naming the view, with a link to review it.
- A filter stopped working. Straight away. Usually an attribute the filter uses was changed or removed in Attio. Views over it keep serving their last good copy and nothing goes offline, but nothing new comes in until the filter is fixed.
- Sources worth a look. At most once a day, a digest of changes that did not need a pause but are worth knowing about, such as a filter that suddenly matches nothing. When that happens we keep showing the last good copy rather than emptying a page your clients are reading.
If your view looks wrong rather than paused, if the view is empty goes through the likely causes in order.
Pause first, ask questions later
If you are ever unsure whether a view should be up, pause it. It is instant, it signs every viewer out, it loses nothing, and publishing again puts the same view back at the same address.
Anything here wrong, or missing? support@publicviews.app.