Sharing
Sharing & embedding
There are two independent questions: who inside the workspace sees a project (public vs private), and whether anyone outside can open a read-only link (the share link). They don't imply each other.
Public vs private (inside the workspace)
Like Slack channels: a public project is visible to everyone in the workspace; a private one only to people explicitly added. The project lead manages this — flipping visibility or adding members doesn't require the workspace owner.
Share links & embedding (outside)
A share link gives read-only access to anyone with the URL — no account needed — and the same view can be embedded in a wiki or doc. It's a separate switch from visibility: a private project can still have a share link, and a public one needn't.
Rotate or revoke the link any time; the old URL stops working immediately. Viewers via a link can't edit, comment, or see anything beyond that project.
What a link viewer can see
- The schedule itself — tasks, phases, dependencies, key dates, progress.
- Not: comments, the workspace, other projects, or the member list.
- Not: any cross-project references — borrowed rows are never exposed through a share link.
“It's private — so there's no public link, right?”
Not necessarily. Visibility (workspace-internal) and the share link (external) are separate. A private project with an active share link is still reachable by anyone holding that URL. Check the share state, not just the visibility, before assuming it's sealed.
Recap
- Visibility — public/private = who in the workspace sees it.
- Share link — read-only, account-free, external; rotate/revoke any time.
- Independent — private can still have a link; check both.