Dashboards & inbox

In one line. The two consumer surfaces where work becomes visible and actionable — the Dashboard (analytics over your project) and the Inbox (the queue of everything waiting on a person). You’ll be able to. Read a project’s Dashboard, find the right widget, and triage the Inbox — knowing exactly where each item gets acted on (not inside the Inbox). Where this lives. Consumer app: App ▸ Overview/Dashboard (address _dashboard) and App ▸ Inbox (address inbox).

Two surfaces, opposite questions

Earlier pages worked one document at a time. This page zooms out to the whole project. Two surfaces do that, and they answer opposite questions:

The Dashboard answers “how is the whole pile doing?” — counts, charts, trends.
The Inbox answers “what is waiting on me right now?” — a worklist of human tasks.

Both are consumer surfaces — what your end-users see and use. You, the builder, configure what they show from Studio. Knowing the consumer side first tells you what you’re configuring toward. If you’re new here, What is Botminds and Core concepts give you the vocabulary this page assumes.

Tip. A common newcomer mistake is to treat the Inbox like an approval screen. It isn’t — it’s a pointer list. The Inbox half of this page makes that concrete.

The Dashboard

Purpose: project analytics — the bird’s-eye view of your documents and the work done on them.

It lives at the Overview / Dashboard tab in the top nav (address _dashboard). If a project has more than one dashboard, each one gets its own tab in a row across the top, and you switch between them there.

Watch out. A project can turn the Overview / Dashboard tab off, and what you see also depends on the access you have been given. If a colleague sees “Overview” and you don’t, that is configuration, not a fault — ask your administrator. See Security & governance for how access shapes what a person sees.

Two modes

The Dashboard surface has two modes, and which one you land in depends on how the project is set up.

DASHBOARD — landing mode (role cards)          DASHBOARD — regular mode (a dashboard)
┌──────────────────────────────────┐          ┌────────────────────────────────────────┐
│  Who are you here as?            │          │ [Operations][Finance][Quality]  + edit │ ← dashboard tabs
│  ┌────────┐ ┌────────┐ ┌───────┐ │          ├────────────────────────────────────────┤
│  │Reviewer│ │Approver│ │Analyst│ │          │ ┌───────┐ ┌───────┐ ┌───────────────┐  │
│  └────────┘ └────────┘ └───────┘ │          │ │ 1,240 │ │ Chart │ │ Status donut  │  │
│  (pick a role → its landing view)│          │ │ Docs  │ │       │ │               │  │
└──────────────────────────────────┘          │ └───────┘ └───────┘ └───────────────┘  │
                                              │ ┌──────────────────┐ ┌─────────────┐   │
                                              │ │Query-builder tbl │ │ Error types │   │
                                              │ └──────────────────┘ └─────────────┘   │
                                              └────────────────────────────────────────┘

Landing mode shows role cards — pick the role you’re acting as, and the dashboard tailored to that role opens. Use this when one project serves several audiences (a reviewer and a finance analyst want different numbers).
Regular mode drops you straight into a dashboard: a row of dashboard tabs (pinnable, favouritable, up to 5 visible) over a grid of widgets.

If a project has no dashboard yet, you’ll see the empty state — “There is no dashboard… Create a new dashboard” — and, for workspace and project admins, a plus button to make one.

What every control does

Control	What it does	Notes
Dashboard tabs	Switch between configured dashboards	Pin / favourite; max 5 visible; each can carry an uploaded icon
Widget grid	The analytics themselves — one tile per widget	Resizable / draggable in edit mode (admins)
Per-widget date range	Restrict a widget to a time window	Lives on the widget, via its query-builder — not a single global date control
Per-widget filters	Query-builder conditions feeding the widget	Configured in Studio; the consumer reads the result
Auto-refresh	Re-pull the dashboard’s data on an interval	Set per dashboard
Edit mode	Add / rename / delete / rearrange widgets	Admins only; you’re asked to confirm if you leave with unsaved changes

What kinds of widgets exist

A dashboard is a grid of widgets. The platform ships several categories — an administrator picks and arranges them in edit mode; everyone else reads the result:

Counts / stat tiles — a single big number (“1,240 documents”, “37 overdue”).
Charts — bar / line / donut style visualisations of a metric over time or by category.
Status & error-type breakdowns — how documents distribute across lifecycle stages or failure reasons.
Tables — including a query-builder table (rows from a saved query) and a chat-table (a table produced by asking a question).
Navigation widgets — tiles that link onward to a filtered list or another surface.

Watch out. Each tile loads its own data, so a dashboard with many tiles takes a moment to fill in, tile by tile. If it feels slow, it is still loading, not stuck.

Tiles are added, renamed, rearranged and deleted on the dashboard itself, in edit mode — so a project admin builds the dashboard on the same screen everyone else reads it on.

Pack tabs — action dashboards on the classic shell

A project can also mount a card-based pack as an additional tab in the top nav, next to Dashboard / Inbox / Documents — the classic tabs stay untouched. Packs are built at Studio ▸ Experience ▸ Designer ▸ Packs. This is how hybrid action dashboards ship: instead of read-only widgets, a pack tab opens card pages such as worklist inboxes with Review / Approve actions, drillable document lists (age / SLA / confidence columns), and KPI or heat-matrix strips — every drill lands on real filtered data. Pack tabs are part of the project’s setup, so everyone working in the project sees the same tabs. Pages, Packs and Cards are on by default, but an administrator can switch them off for a workspace — when they are off, pack tabs are not available. The card layer behind them is covered in Pages & cards.

Behaviours to know

Most people read; admins configure. Everything on a dashboard was set up by someone before you opened it. Anyone can switch dashboards and pick a role card; only an admin can enter edit mode and change what the tiles show.
Unsaved edits are protected. If you’re in edit mode and try to leave with unsaved changes, you are asked to confirm before you go.
It’s role-aware. What an analyst sees and what a reviewer sees can be two entirely different dashboards behind the same tab — that’s the point of role cards.

The Inbox

Purpose: the per-project queue of everything waiting on a person. Where AI hands work back to humans — reviews, approvals, “needs info”, triage, and tasks all land here in one list.

The one thing to understand first

Watch out — the Inbox does not act on items. The Inbox is read + snooze + dismiss only. There is no approve, reject, or edit button inside the Inbox. Each row is a pointer to a document sitting in a human review stage. To actually decide on it, you click Open, which takes you to the wrapped document, and you act there using its normal lifecycle UI (the Summary pane, the workflow stepper). When you advance the document, the Inbox item resolves itself.

Internalise that and the rest of the Inbox is simple. The Inbox is a worklist, not a workspace.

How items get here

Two concepts from earlier pages meet in the Inbox:

The Inbox is a Human-kind collection — recall from Core concepts that a collection’s Kind is either Agent (an AI works it) or Human (it’s a person’s work queue). The Inbox is the canonical Human-kind collection.
Items appear because a document’s Lifecycle reached a stage configured to “send to inbox.” When a document enters that human stage, an Inbox item is created that points at the source document — it carries the collection, the document and the stage it came from. You design that behaviour when you build the lifecycle — see Taxonomy, lifecycle, tags & events.

The Inbox tab lives in the consumer app (address inbox). It can also appear as an Inbox collection tab inside the project — either way opens the same queue.

Header, stats, and filters

The header reads “Inbox · Human intake” with the subtitle “Everything waiting on a person in this project.” Beside it: an “N open” count chip, and a red “N overdue” chip that appears only when some item’s due date is in the past.

Control	Options	What it does
Scope segment	My items (default) · Everyone	Whose items to show — yours, or the whole project’s
Status segment	Open (default) · Snoozed · Done	Which state of the items to list
Refresh	—	Re-loads the current scope + status

The type sections

Items are grouped into fixed-order sections; a section only appears when it has items. Each header reads {label} · {count}:

#	Section	Meaning
1	Needs Approval	An approval decision is required
2	Needs Review	A human review is required
3	Needs Info	Something is missing / sent back for information
4	To Triage	Unclassified, needs routing
5	Tasks	A general to-do

The item card and its actions

Each card shows:

Headline — the item’s title (e.g. “Invoice 4471 needs sign-off”). High-priority items get a red left border.
Provenance line — wraps ▸ {collection} · {document} · {stage} — tells you exactly which document and which stage produced this item.
Meta line — whether the item is assigned to someone, an age label (20m / 3h / 1d), and an optional amount (e.g. $12,400).

Action	What it does	Available when
Open	Navigates to the wrapped document — where you actually review/approve/edit	Only when the item has a source document
Snooze	Hides the item for a while (default 60 minutes), then it returns	Always
Dismiss	Removes the item from the queue	Always

Watch out. There is no claim/assign and no approve/reject/edit here. Assignment is displayed (the item carries an assignee) but not edited in the Inbox. All real action happens on the wrapped document — click Open and use the document’s lifecycle UI (see The document detail page).

Behaviours to know

Snooze and dismiss are instant. Snooze an open item and it leaves the Open list straight away, then shows up under Snoozed — there’s no waiting.
Items self-resolve. You don’t mark an Inbox item “done” by hand for normal work — advancing the wrapped document past its human stage resolves the item for you.
Empty state. When nothing is waiting: a check-circle and “You’re all caught up.” with “New review, approval, and triage items appear here automatically.”

Try it yourself

You’ll need a project with at least one document parked in a human review stage — any use case that routes to review will produce one, e.g. Support intake & triage.

Open the Inbox tab. Read the “N open” chip and note whether an overdue chip is showing.
Flip Scope to Everyone — does the list grow? That tells you whether other people have pending work too.
Find an item and read its provenance line. Which collection and which stage did it come from? That’s your proof that a Lifecycle stage “sent it to the inbox.”
Click Snooze on one item, then switch Status to Snoozed — confirm it moved there.
Click Open on another item. Notice you leave the Inbox entirely and land on the document detail page — that is where you’d approve or edit. Don’t actually decide; just observe that the Inbox handed you off.

If step 5 surprised you, re-read “The one thing to understand first.”

Where to go next

The document detail page — the wrapped document is where reviews and approvals actually happen.
Pages & cards — build the pages, packs and cards that feed these surfaces, at Studio ▸ Experience ▸ Designer.
Taxonomy, lifecycle, tags & events — how a lifecycle stage “sends to inbox.”
Security & governance — how roles gate the Dashboard and other surfaces.