> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Inbox saved views and share links

> Pin a filtered queue to the Inbox sidebar as a saved view, promote it to team scope for the whole workspace, then mint a signed share link so a teammate opens the same filter from a pasted URL. Covers creation, sharing, expiry, and the cross-tenant safety model.

# Inbox saved views and share links

A saved view freezes an Inbox filter — channel selection, statuses, assignee, tags, priority, SLA-breach state, search text — into a named entry the whole queue-working day starts from. Instead of re-picking six dropdowns every morning, pin **Triage: unassigned + urgent** once and land on it every day. This guide covers what a view stores, how to create one from the filter bar, how to share it with a teammate via a signed link, how revocation works, and why a leaked link is not a leak.

<Steps>
  <Step title="Understand what a saved view is">
    A named, permissions-scoped filter snapshot.
  </Step>

  <Step title="Create a view from the filter bar">
    Pick the filters, name it, pin it to the sidebar.
  </Step>

  <Step title="Share a view">
    Mint a signed link and copy it from the Manage views dialog.
  </Step>

  <Step title="Open a shared link">
    Resolve the token; the inbox preloads the shared filter.
  </Step>

  <Step title="Un-share and expire links">
    TTL of 1–90 days, snapshot semantics, audit trail.
  </Step>

  <Step title="Views vs. email notifications">
    Views organize your queue; preferences govern mailbox noise.
  </Step>
</Steps>

## 1. What a saved view is

A saved view is a stored filter object — the same object `GET /inbox/conversations` accepts — written to the tenant with a name, an optional icon and colour, a pin flag, and a scope:

* **Personal** — visible only to you. Any signed-in agent can create, edit, or delete their own personal views.
* **Team** — visible to everyone in the workspace. Creating, editing, deleting, or changing a view's scope (personal → team or back) requires an owner or admin role.

Views live in the Inbox sidebar. A pinned view gets an entry there plus a live count badge fed by `GET /inbox/views/counts`, so you see **Triage: 7** without opening the queue. Deletion is a soft delete, so an accidental click stays recoverable within the data retention window.

Views are a tenant-owned convenience control: they choose which rows the queue renders. The data underneath is still subject to the same assignment, tag, and permission rules — a view is a lens, not an access grant.

## 2. Create a view from the filter bar

In the dashboard's **Inbox**, apply the filters you want — chips above the conversation list reflect every active filter. Under those chips, click **Save view**, give the view a name, choose personal or team scope, and optionally pick an icon, colour, and pin it to the sidebar. If you're promoted past the filter moment, the same dialog is reachable from the bookmark-icon **Manage views** button in the nav rail.

The API equivalent, for scripting or seeding a workspace:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/inbox/views \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Triage — unassigned + urgent",
    "scope": "team",
    "is_pinned": true,
    "filters": {
      "assignee": "unassigned",
      "priority": ["urgent"],
      "statuses": ["open"]
    }
  }'
```

`POST /inbox/views` with `scope: "team"` succeeds only for owners and admins; a personal view is created for anyone signed in. `PATCH /inbox/views/{id}` renames, re-filters, re-pins, or changes scope (scope changes are admin-only), and `DELETE /inbox/views/{id}` soft-deletes. The workspace caps out at 500 live views — well past any sane sidebar.

## 3. Share a view

A team view already appears in every teammate's sidebar, but sometimes you want to point one person at one filter — "work the queue this way for today's incident" — without deciding the whole team's sidebar. A share link does that: it hands over the filter itself, not a sidebar entry.

In **Inbox → Manage views**, open the menu on the view and choose **Copy share link**. That call is `POST /inbox/views/{id}/share`, which mints a tenant-scoped signed token and returns it; the dialog builds the in-app URL (`/inbox/shared/<token>`) and places it on your clipboard, ready to paste into chat.

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/inbox/views/view_9f2d8a/share \
  -H "X-API-Key: dv_live_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{ "ttl_days": 7 }'
```

The filter snapshot is embedded **into the token at mint time**. Renaming, re-colouring, re-filtering, or even deleting the source view afterwards never changes what already-issued links open — the link resolves to the filter you actually shared, not whatever the view later became. Links default to a 30-day lifetime; pass `ttl_days` (1–90) to shorten or extend. Every mint is written to the workspace **Audit log** with the view id, TTL, and expiry, so security reviews can see what links were handed out and when they die.

Share only views you can see: minting enforces the same visibility rule as the view list — personal views only for their owner, team views for anyone in the tenant.

## 4. Open a shared link

Paste the URL and you're on the dashboard's share-link landing page, which asks the API to resolve the token and then forwards you into the Inbox with the shared filter preloaded — including any search term, which fills the search box. The recipient's inbox is filtered identically to yours, but nothing is added to their sidebar and no view is created for them; they can save it themselves if they want to keep it.

The safety model clamps every link to its own tenant:

* **Both ends require login.** Minting and resolving are authenticated API calls — a token in the wild cannot be redeemed by someone outside your workspace.
* **Tenant-bound.** The token carries the tenant id inside its signed payload. A user logged into a different organization who clicks your link gets the same generic failure as an expired link — the filter never travels across tenants.
* **Non-disclosing failure.** A tampered, malformed, expired, or cross-tenant token all return one response: `410 SHARE_LINK_INVALID`. Recipients see "This share link is invalid or has expired" and are pointed back to the inbox; they never learn *which* failure occurred.

Failed resolves (tamper probes, cross-tenant attempts) are written to the audit log, so abuse of leaked links is visible in **Settings → Audit log**.

## 5. Un-share and expiry

There is no server-side register of issued links — revocation works through expiry and view hygiene:

* **Wait for expiry.** The link dies on its `expires_at`, default 30 days. Mint replacements with a shorter `ttl_days` when handing links out broadly.
* **Delete the view.** Soft-deleting the source stops *new* links from being minted; because issued links already carry the snapshot, they keep working until they expire. If a snapshot must also stop resolving, your only practical lever is expiry — mint conservative TTLs for sensitive filters.
* **Rotate broadly.** The signature is minted with the workspace's API secret; links signed under a retired secret fail verification everywhere at once. This is the break-glass, not the everyday control.

Every mint, failed resolve, and cross-tenant block lands in the audit log, so an admin can list outstanding links indirectly: views that were shared, when, and with what TTL.

## 6. Views vs. email-notification preferences

Two inbox "personalization" surfaces solve different problems. A **saved view** answers *"which conversations am I looking at?"* — queue organization. **Email-notification preferences** answer *"when does Orbit email me about the inbox?"* — delivery of alerts outside the dashboard, configured per user from the notification settings covered in [In-dashboard notifications](/guides/in-dashboard-notifications).

Don't confuse either with the workflow automation layer: the [Inbox tickets workflow](/guides/inbox-tickets-workflow) guide covers tags, statuses, SLA policies, and routing rules — the machinery under every filter. Saved views and share links only wrap that machinery into a named, copyable slice.

## See also

* [Omnichannel Inbox setup](/guides/inbox-setup) — channels, routing rules, macros, SLA policies, and the views/bulk-actions section this guide extends
* [Inbox API reference — saved views](/api-reference/endpoints/inbox) — request/response schemas for `POST /inbox/views`, `POST /inbox/views/{id}/share`, and `GET /inbox/views/share/{token}`
* [Inbox tickets workflow](/guides/inbox-tickets-workflow) — statuses, tags, and SLA automation views can filter on
* [In-dashboard notifications](/guides/in-dashboard-notifications) — the per-user notification preference surface, distinct from views
* [Inbox terminology FAQ](/guides/inbox-terminology-faq) — queue language: conversations vs. tickets, assign vs. route