A link should carry its own rules
The same document goes to an investor, a procurement team and a competitor's analyst. Permissions belong to the link you gave each of them, not to the file.
The XDocs team4 min read
Most document sharing starts from the file. You set permissions on the thing, and everyone who gets it inherits them. It works right up to the first moment two audiences need different treatment — which is, in practice, immediately.
A pricing deck goes to a warm lead you want to make it easy for, to a procurement team that will circulate it internally whatever you say, and to somebody at a competitor who signed up with a personal address. One document. Three completely different sets of rules, and one of them you will want to switch off on a Friday afternoon without disturbing the other two.
So in XDocs the unit of sharing is the link, and every link carries its own settings.
What a link can be made to require
| Gate | What it is for |
|---|---|
| Password | A shared secret for a small, known audience. |
| Email capture | Know who is reading. Cheap, and defeated by anybody willing to type a fake address. |
| Email verification | A six-digit code to the address given, which turns a claim into a fact. |
| Allow and block lists | Named addresses, or whole domains, admitted or refused by rule rather than by vigilance. |
| Expiry | Access that ends on a date, because most sharing is about a moment. |
| View caps | A link that stops working after N visits — useful when it will be forwarded. |
| NDA before viewing | Terms presented and accepted before the first page is served, with the acceptance recorded. |
| Watermarking | The reader's own details, composed into the page and the download. |
| Download control | Reading without keeping a copy, when that is the deal. |
None of these is novel on its own. What matters is that they are properties of one link: three links to one document can require three different things, and revoking the third leaves the first two untouched. No file permission model gives you that without a lot of duplicated files. Put many documents behind one set of gates and you have a data room, which is this mechanism with a folder tree on top of it.
Watermarks are composed, not stamped
A watermark that says CONFIDENTIAL deters nobody. A watermark that says the reader's own email address, the date and time they opened it and the IP it was served to changes how a document gets forwarded, because it makes forwarding attributable.
So the mark is a template you write per link — {email}, {date}, {time}, {ip}, {link} — with its position, opacity, rotation, size and colour. And the copy a reader downloads is stamped with the same mark as the one on screen, which is the part that is usually missing: a screen watermark with a clean PDF behind it is theatre.
The question a watermark should answer is not "is this confidential" but "whose copy is this".
NDA terms are written once and picked by name
An NDA gate is only as good as its wording, and wording pasted into a link settings box is wording nobody will ever find again. Terms live in an agreements library instead: write them once under Settings, pick them by name on any link.
Editing a set of terms then raises a question with only one honest answer. Everybody who accepted the old wording is re-asked, because they did not agree to the new text — and each existing record keeps the text that person actually agreed to, rather than being quietly upgraded to the current version. An acceptance record that drifts to match the latest draft is not a record of anything.
A custom domain serves the viewer and nothing else
Links can be served from your own domain. That is a branding feature with a security edge to it, so the edge is deliberately blunt: the root of the domain shows whose documents live there, every other path is a 404, and only that account's links answer on it.
Which means a link domain is never a second copy of the product on somebody else's hostname. There is no sign-in, no dashboard, nothing to probe — just the viewer, and only for the links you published.
Afterwards: who got in, and who did not
Gates generate a second kind of information, and it is easy to throw away. A visit that was refused is as interesting as one that was allowed — more so, when the person was somebody you were expecting.
- Every view is recorded against the link, the document and the visitor, with per-section or per-page reading time.
- Which gate turned a particular visitor away is a question with an answer: a wrong password, an address outside the allow list, an expired link, a cap already reached.
- Webhooks fire on the sharing half as well as the signing half — a link opened, terms accepted, a copy downloaded — so another system can react.
- Internal visits and ignored domains are left out of analytics retroactively as well as going forward, so your own team reading a deck does not look like demand.
And the direction nobody plans for
Sharing has a reverse gear: sooner or later you need documents *from* somebody. A file request is an upload-only page with no view of anything else — a link you send to collect the signed copy, the certificate of insurance, the three years of accounts — which is the same idea as everything above, pointed the other way.
Read next
Set up a diligence room before the first bidder arrives
An hour spent on the index and the permission matrix buys back a fortnight of answering the same question in four different email threads.
Read itReading time only counts when somebody is reading
Most document analytics measure tabs, not attention. Fixing the measurement is the easy half; the hard half is making the number answer a question.
Read itHow to set up a startup data room for a seed round
A seed data room is not a miniature M&A room. It is a dozen documents, a sensible index and two levels of access — and most founders put too much in it, too early.
Read it
One place for every important document.
Create, sign, share and understand your documents with XDocs.