Access and sharing

A view has a password or an allowlist, not both. A viewer would have to pass both, and the password would add nothing: it identifies nobody, and the allowlist already decides who gets in. Choosing one clears the other when you save. A view that still carries both from before this rule is refused at publish until you pick one.

Every new view starts as anyone with the link, so it is never created in a state that would turn everybody away. That is a default, not a recommendation. With a public link the address is the only protection the view has, and an address in somebody’s forwarded mail is still an address anyone can paste.

Email login takes addresses, domains, or both. Domains match exactly: a rule for a company’s domain does not admit its subdomains. A viewer whose address is not covered is simply not let in, and the screen never says which addresses are on the list, so the gate cannot be used to find out who you shared with.

Email verification, and what it proves

With email login on, there is one more switch: Make viewers verify their address by email. It is off by default.

• Off. A viewer types a listed address and is in. The address is a claim, not an identity: anyone who knows a listed address can use it. The access log records the address they typed, and so does any edit they propose.
• On. A viewer types their address and we email them a sign-in link. It works once and only for a short while. Opening it is what proves they hold the mailbox, and from then on the address is an identity. Every address gets the same “check your email” screen and only listed ones get mail, so the gate still confirms nothing about the list.

Two settings force verification on and keep it on while they are on, because each one relies on knowing who the viewer is rather than who they say they are:

• Row scoping, because it decides which rows a viewer sees by their address. See row scoping below.
• Viewer edits without approval, because nobody reviews those changes before they reach Attio. See viewer edits.

While either is on, the checkbox is locked and says why.

End dates and open limits

Both sit on top of whichever way in you chose, and both are on Starter and Pro.

• Close the link on a date. On the Access step itself. A date in the past closes the link immediately, which is the quickest way to shut one you have already sent.
• Close after this many opens. Under Advanced. The count goes up before the view renders, and a link scanner or a chat app’s link preview does not use one up. Once any opens have been counted, the screen shows how many of the limit are used and offers Reset the count to 0.

Both are checked before any password or email, so a closed link never asks a viewer for a credential. A viewer who arrives after either runs out is told the link has expired and to ask you for a new one. Nothing about the view’s data is on that screen.

CSV downloads

Under Advanced, Let viewers download this view as a CSV. It is off by default. Turned on, the published view gets an Export CSV button (it reads Export these while a search or filter is active, and exports just those).

• The file holds exactly what the view holds: the visible attributes, and with row scoping on, only that viewer’s rows. There is no separate export path that could hold more.
• A very large view is cut off at one download’s worth, and when that happens the view says so and says how many rows the file holds, rather than handing over a file that is quietly short.
• Each download is recorded once in the view’s access log as Exported, so you can tell “somebody took a copy” from “somebody read the page”.

Switching downloads on or off takes effect straight away and signs nobody out.

How long a viewer stays in

A viewer who gets past a password or email login is given a session for that one view, so they are not asked again every time they open it. By default it lasts 15 days, it can never last longer than 30 days, and it never outlives the link: a session granted on a link that closes tomorrow ends tomorrow. The session is fixed when it is granted and does not extend itself because the viewer keeps coming back.

A long session does not weaken the gate, because ending access is not the session’s job. These end every open session on the view immediately:

• Pausing the view. The confirmation tells you how many open sessions were signed out.
• Saving any change to who can open it: a new password, an address taken off the list, a different way in.
• Unpublishing or deleting the view.

A session also belongs to one view only. Getting into one view you shared never gets a viewer into another.

Row scoping: each viewer sees only their own rows

Everything above decides who gets the view. Row scoping decides which rows each of them gets, so one link can serve every client, and each sees only the records that carry their own address. It is on Pro.

On the Access step it is under Advanced (Show each viewer only their own rows), and it has a page of its own. You pick one attribute of the records to match against, and the rule is: a viewer sees a row when that attribute holds their verified email address. Matching is on the whole address and ignores capitals. Only email and text attributes can carry a rule, and the picker lists the others with the reason each cannot.

• It needs email login. Row scoping matches an address, so the view has to ask for one. Without an email or domain allowlist, no viewer can prove an address and everyone would see an empty view.
• It forces verification on, and keeps it on while scoping is enabled. A rule matches a verified address or it matches nothing.
• A viewer who matches nothing sees nothing. Not everything, and not a partial set. Missing identity never widens access.
• The matching attribute is never sent to the viewer. The comparison happens in our database. The attribute does not have to be one the view shows, and if it is not, it never reaches the page.
• A newly chosen attribute has to be read first. Until the next sync has read it, rows match nobody, and the page warns you in amber rather than quietly serving everyone an empty view.

Removing the rule from a live view does not widen it: the view is paused instead, and every viewer would otherwise see every row, so you publish it again when you mean to.

There is deliberately no domain mode. Row scoping means “this one person”; “everyone at this company” is what a domain in email login is for.

Changing access on a live view

Open the view and use the editor’s Access row. Changes there wait for the Save button like every other row. When you save a change to who can open it, every viewer currently reading the view is signed out, so nobody keeps a session granted under the old rules. Saving does not re-sync anything and does not clear the cached rows.

The open limit, downloads and viewer edits are one link further in, on Expiry, downloads and viewer edits from the Access row. Turning viewer edits on changes who can read the view too, and the viewer edits guide explains why before you commit.