Most of the people who need to see your work will never sign in to it. A client wants the invoice. An accountant wants one transaction and the receipt attached to it. A collaborator wants to watch a board move without being given the keys to everything else. A screenshot answers the question once and is wrong the moment anything changes.
A share link answers it properly: one URL that opens a read-only view of one thing in your workspace — an invoice, a task, a board, your calendar — always showing its current state, with no account needed at the other end. It's also a bearer credential: anyone holding the whole URL is in, with no sign-in. So this walkthrough covers making one, sending it, understanding what it exposes, and taking it back.
Sharing is part of the Plus and Pro plans. On Free and Starter the Share action still appears, but it's inert and points at the plan page instead. Links are created in the web app; the mobile app's share action opens your device's own share sheet for a file you just downloaded, which is a different thing.
The goal
Give someone outside your workspace a live, read-only view of the one thing you picked — sent with an expiry, revocable at any moment — and know precisely what it does and doesn't reveal.
1. Start from the thing you're sharing
There is no "new link" button on the Shared data page. That page lists what already exists and lets you manage it; every link is created from the record itself. Open the item and press Share.
- Invoice — from the detail page, or from the row actions in the invoices list.
- Document — from the document detail page.
- Transaction — from the row actions in the transactions table, or the header while editing one.
- Task — from the task detail page, or the actions menu of a card opened on a kanban board.
- Kanban board — from the board page, for whichever board is selected.
- Calendar — from the calendar toolbar. Step 4 covers this one, which behaves differently.
- Generated files — an export, a generated invoice PDF, or a generated document PDF. See Export data.
The link shows what you shared and nothing around it. Whoever opens it gets theme and compact-view toggles and no way to change anything, and related records travel only as names: a shared transaction names its client and project, it doesn't open them.
2. Set an expiry, and email it if that suits
The dialog asks two optional things. Set an expiry is switched on by default, with the Expiry date filled in a calendar month ahead, because a URL you can't watch is safer if it stops working on its own. Move the date, or switch Set an expiry off entirely for a link that runs until you revoke it. An explicit expiry can be at most 90 days ahead — the server rejects anything further out.
Send to email takes one or more addresses and mails the link to each of them the moment it's created. It's the same one link in every message, so revoking it later closes every copy at once. Sending is optional; leave the field empty and you'll just copy the URL yourself.
3. Copy it now — the full link is shown once
After creation the dialog reveals the URL. That reveal is the only time it exists in readable form: the server keeps a hash of the token plus a short prefix for identification, so a link you failed to copy can't be recovered from anywhere. Close the dialog without copying and the only fix is to create another one.
You can hold 50 active links at a time. An expired or revoked link frees its slot, which is one reason to revoke rather than let old links accumulate.
4. Share a calendar, and the feed that goes with it
A calendar share is the odd one out: it isn't tied to a single record, and it's the only link you configure while creating it. Choose which families of entries travel — events, tasks, subscription renewals — and whether tasks are narrowed to the projects your own calendar narrows them to. Chip colours and any project filter are taken from your calendar settings as they stand at that moment. Weather never travels, and neither do events pulled in from imported feeds.
Know what you're handing over before you send it. The recipient sees one month at a time and can page backwards and forwards, up to three years either side of today — a calendar link is a window on your schedule, not a snapshot of this week.
Those choices are frozen onto the link. Changing your own calendar settings afterwards doesn't change what an existing link shows, and the choices can't be edited later — quietly widening a URL already sitting in someone's inbox is a change you'd have no way to observe. To share differently, revoke and create a new link.
One extra toggle, off unless you turn it on, adds a subscribable feed: a second address alongside the browser link, one a calendar app can subscribe to so the entries appear there and refresh on their own. It shows exactly what the browser link shows, and revoking the link stops both.
5. Know where the token lives
For the link you open in a browser, the part that grants access sits in the URL fragment — everything after the #. A browser never sends a fragment to a server, so the token stays out of request logs, out of tracing spans, and out of the Referer header sent when the viewer clicks away from the shared page. The page reads it locally and passes it in a request header instead.
The subscribable calendar feed is the exception. A calendar app fetches a plain URL and runs no code, so it can't lift a token out of a fragment or attach a header; that feed carries its token as a query parameter instead, which does reach the server. It's stripped from the logged request URL before the line is written, but it's genuinely in the URL rather than shielded by the fragment.
Either way, treat the whole URL as a password. Send it the way you would send a password, set an expiry where you can, and revoke it once it has done its job.
6. Revoke it when the job is done
The Shared data page is the register: every link with its type, the record it points at, its token prefix, its status, its expiry, when it was last opened, and how many times. That view count is the one signal you have that a link has travelled further than you meant it to. A link you sent to one client and that has been opened forty times has almost certainly been forwarded — revoke it and send a fresh one to the person who should have it.
Two actions sit on each row. Edit expiry sets, moves, or clears the date. Revoke disables the link permanently: anyone using it loses access immediately, and it can't be undone — but a fresh link can always be created. Select several rows to revoke them together.
A link is also suspended on its own if your plan stops covering sharing, or stops covering the feature it shares — a board link on a plan without kanban, say. Upgrade again and the same links start working; you don't have to recreate them.
What you end up with
One deliberate slice of your workspace in someone else's hands, read-only and current, with a date it stops working and a switch that kills it sooner. For most links that slice is a single record. A board link carries every task on the board, and a calendar link carries a window on your schedule three years either side of today — which is why those two are worth a second thought before you send them. Nothing outside the slice you chose is reachable from any of them, no account was created at the other end, and the register on the Shared data page tells you what's still open and how often each link has been used.