Access levels explained

Sharing is where a lot of document tools quietly get sloppy. The link works, the gate looks convincing, and underneath it the content was in the page all along, waiting for anyone who opened the developer console.

Docutrain checks a document's access level on the server, on every request: loading the page, sending a message, fetching a reference. The passcode is never in the page. The page only knows that one is required. Which makes the interesting question not whether the gate holds, but which gate to use.

The six levels

Every document carries exactly one, set in the editor under Settings → Access.

Two practical notes. Public and Passcode are paid-plan features, so on a plan without public sharing those tiles carry a lock and open an upgrade prompt rather than changing anything. And the two organization-scoped levels need the document assigned to an organization before they will switch on.

For internal content those last two do most of the work. Owner group covers everyone connected to the organization. Owner admins only narrows it to administrators, which makes it a sensible parking space for drafts. Who is in a group, and how they got there, is users, roles and invitations.

Passcodes are blunt. Token links are not.

A passcode is the obvious choice and it works. Pick Passcode, type one into the tile, hand out the link. Readers are prompted once, and a correct entry is remembered on their device for about three months so they are not asked again on every visit.

Its limitation shows up the first time you want to take access away from one person. You cannot. Changing the passcode revokes everybody at once, and every reader gets prompted again on their next visit, including the ones you were happy with. For a conference handout that is fine. For a client, a contractor, or anyone whose relationship might end before the document does, it is the wrong tool.

Token links are the per-recipient version. Each token you issue takes an optional name for your own reference ("Conference attendees", "Acme pilot"), an optional expiry date, and an optional maximum number of uses. The token is baked into the link, so recipients never type anything, they just click. Afterwards you can copy the link, edit the expiry, switch the token between active and inactive, or delete it outright. The list shows uses so far and uses remaining, with statuses like Expired or Maxed out.

The counting is more thoughtful than it first appears. A use is recorded when someone arrives through the link, and then the token is remembered for the rest of their browsing session, so moving between pages or coming back an hour later does not quietly burn a second use out of a limit of five. Signed-in members of your own organization do not consume uses at all.

One sequencing quirk: tokens are issued against a saved document, so the access chooser you see before an upload offers every level except Token link. Train the document first, then switch.

Being turned away, gracefully

When someone is refused, what they get is specific rather than a generic wall. A passcode document shows a Passcode Required screen carrying your organization's logo and an entry field. A token-gated one shows Access Token Required and, importantly, nothing to type, because there is nothing they could type. They need the right link. A signed-out visitor to a members-only document is sent to sign in and then returned to the document. Someone signed in but not permitted is told plainly that they lack permission, instead of being bounced somewhere confusing.

Two switches that are not access levels

Document status takes a document out of circulation entirely. Reversible, and the right move for a draft you are not ready to delete. Inside a collection, a paused document stays a member and stays ticked in the editor, marked Paused, but is not served and is left out of collection-wide chat.

Collections have the same switch. Turn one off and visitors following the link land on a Collection Offline notice instead, checked before any passcode or token, which also takes down that collection's shared-conversation links and contact form.

Disclaimers are a third thing again: not a restriction on who may enter, but on what they must agree to first. A collection can replace every per-document disclaimer with one covering chat across all of them.

Where the rules travel

A collection's gate wins inside the collection. Anyone who can open the collection can open every document in it, including documents whose own level is stricter. That is deliberate, since a bundle you hand someone should not fall apart in their hands, and the editor warns you with a confirmation dialog when you bundle protected documents. Outside the collection, each document's own level applies again as normal.

Embeds inherit, they do not escape. Drop a passcode-protected document into your website and the embed asks for the passcode. The share tab tells you this directly rather than letting you discover it from a confused visitor: if the document is not public, people using these methods will meet a login wall or a prompt. See embedding on your website.

Shared conversations inherit too. A recipient still has to pass the document's gate, so sharing a chat never leaks protected content to someone who could not have opened it themselves. Where a thread can no longer be continued, because the document was deleted or access withdrawn, the conversation is still shown in full, read-only, with a short amber note explaining why. More in sharing and exporting answers.

One last distinction, and a useful one: reachable is not the same as findable. Discoverable in search puts a public document into Docutrain's own results. Include in sitemap hands it to external search engines. Turn both off and you have an unlisted public document, open to anyone with the link and advertised nowhere.

Start with the least permissive level that works, and widen when something forces you to. When you are handing access to named people you may one day want to un-name, reach for a token link rather than a shared passcode.