Privacy policy

1. Who this is about, and the 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 views we serve on a publisher’s behalf.

Two very different people appear below and the difference between them decides almost everything else. A third appears once, in section 5, and is neither:

• 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 view. They have no account with us. For the records on that view, 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.
• A release subscriber has no account and has opened no view. They asked us, from this website, to write to them when we ship a release. For that address we are the controller, and section 5 is the whole of what we do with it.

If you are a viewer and you want to know why your details are on a view, 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. If you sign in with Attio, Attio confirms who you are and we keep the identifier it returns; no other identity provider is involved.
• 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.
• How you found us: if you arrived through a campaign link, a PublicViews badge on somebody’s view, or a partner’s referral link, the details described in section 6 are stored with your account or workspace when you create it.
• Partner program, whether or not you are also a publisher: if you apply, your name, email address, company, website, the link you asked for, your preferred payout method and how you plan to promote us. Once you are a partner, the clicks on your links, the workspaces credited to you, and the commissions and payouts owed. A click records the page it came from, never who clicked.
• Support: whatever you send us by email, and whatever you type into the chat widget on this website or in the dashboard. The chat is run for us by Unthread, who therefore hold the conversation. While you are signed in we identify you to it by email address, so a reply reaches the right person and a returning conversation is not a stranger’s.
• Product milestones, in our own customer record: when you sign up, create a workspace, connect Attio, publish a view, invite a teammate, run into a limit on your plan, open the billing screen, or change or cancel a subscription, we record that it happened, when, and which account it was. We keep it in our own CRM, which we run ourselves, alongside your name, email address, workspace name and plan. We use it to understand how the product is used and to decide who to talk to. None of your view data is part of this: no cached records from your Attio workspace, nothing about your viewers, and no contents of any view. It is not sold, not shared, and feeds no advertising. Tell us at support@publicviews.app and we will stop recording milestones against your account.

3. What we cache from your Attio workspace

Published views 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 view, 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 view gated by email, the address the viewer gives. The publisher decides whether it must be confirmed from the viewer’s inbox. A confirmed address is held in the viewer session, which is purged aggressively, and in the per-viewer access log available on the Pro plan, which is kept for that plan’s analytics retention. An address that was typed but not confirmed is held only in the viewer session, and is shown to the publisher as unconfirmed. Neither is written to a log line or into an analytics rollup.
• Sign-in link tokens, stored only as a SHA-256 hash alongside the address the link was sent to, and consumed once.
• Edits a viewer submits, on a view where the publisher allows editing: which attribute, the new value, the value it replaced, and when. The edit is linked to the viewer’s session, which is how the publisher’s edit queue shows who made it. Edits are kept for as long as the view exists, as the record of changes to the publisher’s data.
• Visit events, so the publisher can see whether anyone opened the view.
• 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 view was opened. It is not added to any mailing list, ours or the publisher’s, and that includes the release list in section 5. The only way onto that list is to ask for it here and then open a link we send.

5. What we hold about a release subscriber

There is one list we run for ourselves. It sends one kind of message: a short note when we ship a release. You can join it from the changelog or the roadmap.

• What is stored: your email address, whether it is confirmed yet, the page the button was pressed on, two random tokens, and the dates the row was created, confirmed and last changed. No name, no IP address, no browser, no link to any account, and nothing else. The address is never written to a log line.
• Why: to send you those messages, and for nothing else. It is not used for advertising, is not profiled, is never sold or shared, and does not reach any publisher.
• On what basis: your consent, given twice. The address is inert until you open the link we send to it, so nobody can put an address on this list that they do not control, and an address typed by somebody else never becomes a subscription.
• How long: until you leave. An address that is submitted and never confirmed is deleted after two days, because nobody consented to us holding it.
• How to get out: the link at the end of every message we send, including the first. It takes one press, needs no sign-in and asks nothing further, and it deletes the row rather than marking it. We keep no suppression list: holding an address specifically because its owner asked us to stop would be the opposite of what they asked for.

6. Cookies and other browser storage

We set no advertising cookies, run no third-party analytics, and load no advertising script anywhere. Analytics are our own and stay in our database. A published view loads nothing from a third party at all.

There is one third-party script and it is the support chat, on this website and in the dashboard only. Loading it tells Unthread your IP address, your browser and which page you were on, and it keeps its own identifiers in your browser so a conversation survives a reload. It is there to answer you, not to follow you: it is on no published view, and if you would rather it never loaded, block dialed.unthread.io — nothing else on these pages depends on it.

The cookies we set ourselves 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.
• An attribution cookie on this website, set when you arrive. It holds where your first and most recent visits came from: the campaign parameters in the link, the referring site’s name (never the full address), the page you landed on, and the PublicViews badge you followed, if any. It holds no identity, lasts 30 days, is never read on a published view, and is used only if you create an account.
• Partner referral cookies, set only when you arrive through a partner’s referral link: which partner, which click and which of their links. They are HTTP-only, last 30 days, and are read only if you create a workspace in that time, so the partner is credited.

7. 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.
• Consent: the release list in section 5, and only that. It is the one thing here you opt into rather than receive as part of the service, which is why it is confirmed from your own inbox and why leaving deletes the record.
• Legal obligation where one applies, such as retaining billing records.

8. 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.

9. 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, transactional email goes through Resend, and support conversations sit with Unthread. EU data residency is not available.

10. 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: 15 days by default and never more than 30, never past the end date of the link, 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 Starter and 24 months on Pro.
• Records of deleted items: 30 days, then removed.
• Rate limiting counters: cleared daily.
• Support conversations, by email or in the chat: kept while they are useful for answering you and for the history that makes the next answer better. We have not settled a period for them, and rather than invent one it is listed in section 16.
• Account and billing records: for as long as the account exists, and then only what we are required to keep.

11. 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.

12. 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 support@publicviews.app and we will act on it.

If you are a viewer rather than a publisher, the organisation that published the view 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.

13. Security

The mechanisms are described in specific terms on the security page. We do not hold SOC 2 or ISO 27001 certification and have not had a third-party penetration test.

14. Children

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

15. Changes

When this policy changes, the new version replaces this page. For a change that materially affects publishers, we will email account holders rather than relying on you to check.

16. 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;
• the retention period for support conversations, and the deletion route for a chat transcript held by our support provider rather than by us.

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