PublicViews

Docs

PublicViews turns an Attio list or a filtered object into a web page you control. These pages describe what it does today, including the parts it does not do.

Where this stands

PublicViews has not launched. This is not a finished manual, and we would rather publish the three pages that are accurate than a navigation tree full of empty sections. If you need something that is not here, email help@publicviews.app and the answer will usually become one of these pages.

Guides

  • Publishing a view, screen by screen. The manual. Every screen in the order the product puts them in, what each publish refusal means, and what to check when the page comes up empty.
  • How to share an Attio list. The whole path, from connecting a workspace to sending the link. About five minutes.
  • Attribute type support. Which Attio attribute types render on a page, and the shorter list a viewer can edit.
  • API. What exists, what does not, and what we would build first.

The shape of the product, in one page

A view — the product calls it a page once it is published — is one URL. It carries where its records come from, a layout, the set of attributes a viewer can see, the smaller set a viewer can propose changes to, and an access policy. The records are an Attio list or object, optionally narrowed by one of your Attio saved views or by a filter you build; you choose that on the one screen that creates the page. A view can also scope rows per viewer, matching one attribute against the address a viewer confirmed, which is how one link becomes a different page for each of them.

A viewer is whoever opens the link. They have no account with us and no Attio seat. On a gated view they confirm an email address and nothing more.

Where the data lives

We cache the records behind a published view rather than calling Attio when someone opens the page. Two consequences worth knowing before you build anything on this. Pages load without spending your Attio rate limit, however much traffic a link gets. And the page is as current as the last check, not as current as Attio, so every page carries the time it last updated.

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 source that matches more than 50,000 records is checked every six hours, on either plan. 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. Every plan has a Sync now button for the ten minutes before a client call. Nothing here is event-driven yet, so we quote the interval rather than a promise about seconds.

What we store is the projection: the attributes your views need, and nothing else. The security page sets that out in full, including the two kinds of attribute we hold and never display.

Editing

A viewer’s change never goes straight into Attio. Mark an attribute editable and a viewer can propose a value; it waits in your dashboard beside the value Attio holds now, and it is written when you approve it. Approval is the only edit mode in this version.

What it does not do

  • It does not follow relationships several objects deep. A view shows a list’s records and their direct attributes.
  • It does not let a viewer create records. There is no form mode in this version.
  • It is not an application builder. There are no custom pages, no roles, and no logic. If you need an application, buy one.
  • It does not serve a view from your own domain. Custom domains are not available yet, on any plan, and every published view is served from a publicviews.app link. The roadmap says where that sits.