PublicViews

Unreviewed draft · not in force

A lawyer has not read this page.

This document was drafted in-house, against how the product is actually built, so that a lawyer has something specific to review. That review has not happened yet. It is not in force, it is not a contract, and nothing here binds you or us. It will change before launch. If you need something you can rely on today, write to help@publicviews.app and ask for it.

Drafted 20 August 2026 · never reviewed · never in force

Privacy policy

What PublicViews holds, why, where it lives, how long it stays, and how it is deleted. Written against how the product is built rather than from a template.

1. Who this is about, and the two kinds of people in it

PublicViews is a service that publishes a chosen slice of an Attio workspace as a web page. It is operated by Dialed Technologies. This policy covers publicviews.app, the publisher dashboard, and the published view pages we serve on a publisher’s behalf.

Two very different people appear below and the difference decides everything else:

  • A publisher is our customer. They hold an account, connect an Attio workspace, and decide what is published. For their own account data we are the controller.
  • A viewer is somebody who opens a published page. They have no account with us. For the records on that page, and for a viewer’s email address collected by a gate, the publisher is the controller and we are the processor. We act on their instructions, which are the view configuration and the access policy they set.

If you are a viewer and you want to know why your details are on a page, ask the organisation that sent you the link. We will help them answer, and we cannot answer for them.

2. What we hold about a publisher

  • Account: name, email address, and either a hashed password or the identifier from the sign-in provider you used. Sign-in runs inside our own application against our own database; there is no third-party identity vendor holding your login.
  • Workspace: the organisation record your views belong to, its plan, and who is a member of it.
  • Attio connection: the workspace identifier and an access token, which is encrypted at rest with AES-256-GCM under a rotatable key. We never see or store your Attio password.
  • Configuration: your sources, views, field settings, access policies and branding.
  • Audit log: the record of changes to what is published, who made them and when. This exists so you can answer questions about your own exposure.
  • Billing: plan and subscription state. Card details are handled by our payment provider and never reach our servers. Billing is not switched on yet.
  • Support: whatever you send us by email.

3. What we cache from your Attio workspace

Published pages are served from a cache rather than by calling Attio on each request, so we store a copy of the records behind each published view. The rule is narrow and it is the same rule the software enforces: we store the union of the attributes your views need, and nothing outside that set is ever written to our database. That set is:

  • the attributes you switched on for a viewer to see;
  • the attributes you marked editable, which are always also visible;
  • the attribute a board layout groups by, which is likewise visible;
  • an attribute used to sort the page, which is stored and never displayed;
  • an attribute used to decide which viewer sees which rows, which is stored and never displayed;
  • a linked record’s identifier and display name, where the linking attribute is visible.

Attributes your filter tests are not stored at all, because Attio evaluates the filter. The exposure preview in the dashboard lists everything in the set, including the two kinds we hold and never display, so no publisher is surprised by what we keep.

These records may contain personal data about the publisher’s contacts. The publisher chose which attributes to include and is the controller for them.

4. What we hold about a viewer

  • On a gated view, a verified email address. Exactly two tables hold one: the viewer session, which is purged aggressively, and the per-viewer access log available on the Business plan, which is kept for that plan’s analytics retention. Neither value is written to a log line or into an analytics rollup.
  • Sign-in link tokens, stored only as a SHA-256 hash and consumed once.
  • Page view events, so the publisher can see whether anyone opened the page.
  • IP addresses, stored hashed, for rate limiting and abuse protection.

An email address given to a gate is used to check access and to record that the page was opened. It is not added to any mailing list, ours or the publisher’s.

5. Cookies

We set no advertising cookies and run no third-party analytics or advertising scripts, on the marketing site or on published pages. Analytics are our own and stay in our database. The cookies that exist are functional:

  • A publisher session cookie on the dashboard, so you stay signed in.
  • A viewer session cookie on a gated view, scoped to that one view’s path so the browser will not send it to any other view, marked HTTP-only, and signed with a secret that is not the publisher one.

6. Why we are allowed to hold it

  • Performance of a contract: running the account and the service you asked for.
  • Legitimate interests: keeping the service secure and available, preventing abuse, and answering support requests.
  • On the publisher’s instructions: everything we do with cached Attio records and viewer identities, where we act as processor rather than controller.
  • Legal obligation where one applies, such as retaining billing records.

7. Who else can reach it

The infrastructure and service providers we use, each named on the subprocessors page with what they do and what they can reach. We do not sell personal data, we do not share it for advertising, and we do not use customer data or cached records to train machine learning models.

Attio is not on that list, and the distinction matters: Attio is the publisher’s own system and the source of the data, not a vendor we send data to.

8. Where it is held

In the United States. The database runs on Neon in AWS us-east-2 (Ohio). The application is hosted on Vercel, background jobs run on Trigger.dev, and transactional email goes through Resend. EU data residency is not available.

9. How long we keep it

  • Cached records: for as long as a view that needs them is published. They are purged when the last view bound to that source is deleted, when the workspace is disconnected, or when the account is deleted.
  • Viewer sessions: short-lived, and revoked when a view is paused, unpublished, or has its access policy changed.
  • Sign-in links: 15 minutes, and single use.
  • Analytics and the per-viewer access log: the retention your plan sets, currently 30 days on Free, 12 months on Pro and 24 months on Business.
  • Records of deleted items: 30 days, then removed.
  • Rate limiting counters: cleared daily.
  • Account and billing records: for as long as the account exists, and then only what we are required to keep.

10. Deleting it

Three procedures, and none of them is a bare delete:

  • Delete a view. The view is paused and viewer sessions are revoked, the action is written to the audit log, viewer sessions and sign-in tokens are purged, the cached records for its source are purged unless another view still binds them, and the view and everything hanging off it are removed.
  • Disconnect a workspace. Every cached record from it is purged, the stored token is overwritten, and the views built on it are paused rather than deleted so that reconnecting does not mean rebuilding. Your Attio data is untouched.
  • Delete the account. Every view is paused and audited, every connection is disconnected, and the deletion cascades through every table carrying your workspace identifier. A check afterwards queries for any row anywhere still carrying it. This has to complete without anyone here intervening, because a controller’s erasure request cannot depend on our goodwill.

11. Your rights

Depending on where you live, you may have the right to ask for a copy of your personal data, to have it corrected or deleted, to object to or restrict how it is used, and to receive it in a portable form. Write to help@publicviews.app and we will act on it.

If you are a viewer rather than a publisher, the organisation that published the page is the controller and your request should go to them. Send it to us anyway if you cannot reach them and we will pass it on and help them act on it. You also have the right to complain to your data protection authority.

12. Security

The mechanisms are described in specific terms on the security page, including what we do not have: no SOC 2, no ISO 27001, and no third-party penetration test.

13. Children

PublicViews is a business tool. It is not directed at children and we do not knowingly collect their personal data.

14. Changes

When this policy changes we will update the date at the top. For a change that materially affects publishers, we will email account holders rather than relying on you to check.

15. What is still missing

The parts a lawyer has to supply, listed rather than invented, so nobody mistakes an omission for a decision:

  • the exact legal entity name, company number and registered address of the operator;
  • the governing law, and whether a UK, EU or US framing leads;
  • whether an EU or UK representative is required, and whether a data protection officer must be appointed;
  • the transfer mechanism for personal data reaching the United States, and the standard contractual clauses that go with it;
  • state-specific disclosures for US privacy laws, and the notices they require;
  • the retention period for billing records, once a tax jurisdiction is settled.

Until those are filled in by somebody qualified, this page describes what the software does. It is not a policy you can rely on.