Open app →
Documentation

Public sharing

Publish boards, saved views, and meetings to no-login links backed by revocable, unguessable tokens, with a guest Ask scoped to shared content.

The sharing model

Most of Elliptic lives behind a login, scoped to your organization and your project memberships. Public sharing is the deliberate exception: a handful of surfaces you can open up to people who do not have an account, so a board, a page, a saved view, or a meeting can be read by anyone holding the link. Every one of these surfaces works the same way under the hood, which makes the model easy to reason about and easy to undo.

When you publish something, Elliptic mints a secrets-based token, a long, unguessable random string, and that token becomes the public URL. The token is the only thing standing between the world and the content, so the link is the secret. Nothing about the public surface is searchable or listed: the only way in is the link itself. Share it with the people who should see it, and treat it like a password.

Public surfaces are read-only or narrowly scoped by design. A public board shows only the task attributes you choose. A public view is a read-only list of tasks. A shared meeting shows the summary and, only if you opt in, the transcript. No public surface lets an anonymous visitor change anything inside your org.

And every public surface is revocable. Publishing is reversible at any moment: unpublish a board or a view and the token is cleared, so the old URL stops resolving and returns a not-found page. Revoke a meeting share and the link goes dead. There is no separate cleanup step, the link simply stops working the instant you pull it.

Visibility caveat
A public link is a capability, not a wall. Anyone who has the URL can open it, and they can forward it. Elliptic does not log anonymous readers in, so you cannot tell who has visited. If something must never leave the org, do not publish it. If you published and changed your mind, unpublish or revoke immediately. Note that re-publishing the same thing mints a brand-new token, so the previous link stays dead.
Air-gapped instances
If your Elliptic is self-hosted on a private network, public links resolve only to people who can reach that network. A public board on localhost or an internal host is public only to those already inside the perimeter. On the hosted instance at elliptic.sh, a published link is reachable from the open internet. Know which one you are on before you share.

Because agents are first-class members of your org, the same publish and revoke actions are available to them over the company-brain MCP. An agent can mint, change, or revoke a meeting share through create_meeting_share, update_meeting_share, and get_meeting_share, on your org's own key, exactly as a person would from the web app.

Public boards

A public board publishes a project's Kanban board to a no-login URL. It is the right tool when you want an external partner, a client, or the whole company to follow a project's progress without giving anyone a seat in your org. Visitors see the board grouped into status columns exactly as your team sees it, but as a read-only snapshot they can never edit.

What makes a public board safe to share is that you decide, attribute by attribute, how much of each task is exposed. A task always shows its identifier (like WEB-42) and its title. Everything beyond that is opt-in. You choose from four extra visible attributes, plus status, which is always the column grouping:

  • Priority, the task's priority level. A task whose priority is none shows no priority badge.
  • Assignee presence, whether the task is assigned or not. The board shows an assigned badge, never the person's name or identity, so you can signal that work is owned without exposing who owns it.
  • Due date, the task's due date.
  • Labels, the names of the labels attached to the task.
  • Status, which is always how the board is organized: tasks are grouped into one column per status, so status is shown whether or not you select anything else.

The board only ever shows real, active work. Archived tasks are excluded, and so are triage items (inbound, unaccepted work waiting in the triage queue). Tasks appear in the same order your team sees them on the board, and the public page hides any status column that has no tasks in it, so the link stays tidy.

  1. Open the project board
    Go to the project whose Kanban board you want to share.
  2. Publish the board
    Choose to publish the board. Elliptic mints a token and gives you a public path of the form /public/boards/<token>.
  3. Pick the visible attributes
    Select which of priority, assignee presence, due date, and labels should appear. Anything you do not select is simply absent from every card. Status is always shown as the column grouping.
  4. Share the link
    Send the URL. The reader lands on a page headed "Public board · read-only". They see your columns, cards, and only the attributes you chose.

You can change your mind without re-sharing. Updating the board's privacy keeps the same token and the same URL, it only changes which attributes are visible. So you can tighten a board (drop labels, hide due dates) or loosen it later, and everyone holding the existing link sees the change the next time they load it.

Unpublishing a board clears its token. The old link returns a "Board not found" page that tells the reader the link has been unpublished or does not exist. If you publish the same board again later, it gets a fresh token, so the previous URL never comes back to life.

Attribute changes are filtered
Only the five recognized attributes (status, priority, assignee, due date, labels) are ever honored. Anything else you pass is dropped on the way in. There is no way to expose task descriptions, comments, assignee names, or any other field through a public board, the surface is intentionally limited to these five.

Public views

A saved view is a named, filtered slice of your tasks (by status, assignee, label, or search). A public view publishes that saved view as a read-only link. It is the lightest of the public surfaces: where a public board shows a whole project's columns, a public view shows exactly the filtered list of tasks the view defines, and nothing more.

Publishing a view mints a token and a path of the form /public/views/<token>. The reader sees the view's name and its tasks, each with its identifier, title, status, and priority. As with public boards, archived and triage tasks are excluded, and the view's own filters are applied, so the public list mirrors the view's definition. There is no editing and no per-reader gating: anyone with the link sees the same read-only dataset.

Only someone who can modify the view can publish or unpublish it. Personal views are publishable by their owner, teamspace views by a team member or an admin, and org-wide team views by an admin. Unpublishing clears the token and the old link returns a "View not found" page.

Board or view?
Reach for a public board when you want partners to see a project's full Kanban with columns and chosen attributes. Reach for a public view when you want to expose one focused, filtered list, for example "open bugs labeled customer" or "everything in review", without the rest of the board.

Shared meetings with guest Ask

A shared meeting publishes a single meeting to a tokenized link at /share/meetings/<token>, so someone who was not in the room, and who has no account, can catch up. The guest view leads with what matters: the meeting title, the AI summary, the action items, and the decisions, pulled from the meeting's latest summary. It deliberately surfaces what was decided and who owns what, rather than replaying the whole conversation.

The full transcript is optional. When you mint a share you choose whether to include it, and the default is off. With the transcript off, guests see only the summary, action items, and decisions. With it on, the guest view adds the timestamped, speaker-attributed transcript below the decisions. This lets you share an outcome without exposing every word that was said.

Guest Ask

Every shared meeting carries a guest Ask panel, headed "Ask about this meeting". A visitor can type a question and get an AI answer, with no login. The answer is scoped strictly to the shared content. If the transcript is included, the model answers from the transcript. If it is not, the model answers from the summary instead. Nothing else in your org is ever in scope, the guest cannot reach other meetings, tasks, or notes.

If there is no shared context to answer from (no transcript and no summary), the guest Ask says so plainly rather than guessing, returning a message that there is not enough shared context to answer. Each answer also carries a grounded flag under the hood, signalling whether it was actually backed by a transcript or a summary. The page reminds guests, in a line below the Ask box, that AI answers are scoped to the meeting and that anything important should be verified.

Whose key runs the guest answer
There is no anonymous AI budget. A guest's question runs on your organization's own model key (BYOK), on behalf of the meeting's owner. The guest never sees or supplies a key. Your org pays for, and controls, the model that answers, the same key that powers every other AI feature in Elliptic.

You stay in control of a share after you mint it. You can toggle the transcript on or off at any time, which changes both what guests see and what their Ask can draw from, and you can revoke the share entirely. A revoked link goes dead immediately and the guest page shows "This link is no longer available", suggesting they ask the owner to share it again. Re-sharing the same meeting re-enables the existing token, and the transcript setting you pass takes effect. Only the meeting's creator or an org admin can create, change, or revoke a meeting share.

  1. Open the meeting
    Go to the meeting you want to share. Make sure it has been summarized, the summary, action items, and decisions are what guests see first.
  2. Create the share
    Mint a public share and decide whether to include the transcript (it is left out by default). Elliptic generates the /share/meetings/<token> link.
  3. Send the link
    Share the URL. Guests land on the summary, action items, and decisions, plus the transcript if you included it, and can ask questions in the guest Ask panel.
  4. Adjust or revoke
    Later, toggle the transcript or revoke the share. Revoking kills the link at once. Toggling the transcript reshapes both the view and what guest Ask can ground on.

At a glance

SurfacePublic URLWhat's exposedDirection
Public board/public/boards/<token>A project's Kanban grouped by status, with the task attributes you chooseRead-only out
Public view/public/views/<token>A saved view's filtered task list (identifier, title, status, priority)Read-only out
Shared meeting/share/meetings/<token>Summary, action items, decisions, optional transcript, plus a scoped guest AskRead + ask out
Public intake/intake/<token>A no-login form that submits a request into a project's triage queueSubmit in

Every row above mints a revocable, secrets-based token, and every one can be pulled back the instant you no longer want it open. When in doubt, publish narrowly, share the link only with the people who need it, and revoke the moment the work is done being public.