Roadmap

In the launch build

The version you will be able to pay for. Everything in this section is being built now.

• Connect an Attio workspace over OAuth, and publish from a list or from an object with a filter.
• Table, board and record layouts, all three on every plan including free.
• Per-attribute visibility, hidden by default, with reordering and renaming, and the exposure preview at publish.
• Access gates: unlisted link, password, email allowlist, domain allowlist with a confirmation link, expiry by date or by number of opens, and read access set separately from edit access.
• Per-viewer row scoping. A viewer sees only the records that match their verified identity. This moved forward into the launch build rather than waiting, because it is the difference between a client portal and a page that happens to be gated.
• A scheduled check against Attio, at the interval your plan sets, plus Sync now on every plan, plus the timestamp on the page so a viewer can see it too.
• Editing by approval. A viewer proposes a change to an attribute you marked editable; you see it beside the value Attio holds now and approve it into the record. With validation, an audit log, and rate limits.
• Branding: logo, colours, page title, favicon, and the badge removed on paid plans.
• Analytics: page views on every plan, with unique viewers, referrers and edit counts on paid, and a per-viewer access log on Business.

Right after launch

• Billing for the paid plans.
• Webhook-assisted freshness, on top of the scheduled check rather than instead of it. It is gated on capturing one real delivery from Attio and comparing it against what the documentation claims, which has never been done. When it ships, the freshness wording on this site changes once, and the interval stays behind it, because the scheduled sweep is what makes removals and edits correct.
• A publisher API, if the requests come in. What we would build first is on the API page.

Further out

• Custom domains. Claiming a hostname and verifying its DNS are built. What is not built is the routing that makes a request to that hostname serve your view, and that touches how every request in the product is routed, publisher and viewer alike. It is not being built now, and until it is, every published view is served from a publicviews.app link. Nothing on this site sells a custom domain.
• New-record submission, so a page can take an entry as well as show one.
• Board drag to change status, staged for approval like any other edit.
• Conditional visibility, so an attribute can be shown to one audience and not another.
• Rendering related records across objects, more than one hop from the source.
• More than one publisher on an account, with roles.
• A listing in Attio’s own app store.

Decided against, and why

Two things that would look like features on a roadmap and are deliberately not here.

• A viewer’s edit going straight into Attio. Not deprioritised. Cut. A synchronous write means the published page itself calls your CRM, which is the one thing this architecture refuses, and Attio’s API offers no conditional write and no version to check against, so an unreviewed write is a silent overwrite of whatever a colleague changed a minute earlier. If it ever returns it will be behind a plan capability and a per-view opt-in, and it will never be the default.
• Serving published pages from a shared cache. It would make pages marginally faster and it would make pausing a view eventually consistent. Those two cannot both be right, and on this product the second one decides it.

What would change this order

Customers. The order above is our best guess from the conversations we have had, and one concrete request from someone with the problem outranks a guess. If something you need is in the wrong section, say so: help@publicviews.app. Shipped work shows up in the changelog.