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 (route _dashboard) and App ▸ Inbox (route 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 (route _dashboard). If a project configures more than one dashboard, each gets its own button, and the URL carries ?did=<dashboard-id> to pick which one.

Flag-gated and role-gated. The Dashboard tab is hidden when the project sets the DisableDashBoard flag, and it is not shown to the client role at all. If a consumer can’t see “Overview”, that’s why — it’s intentional, per-project, per-role configuration. See Security & governance for how roles gate surfaces.

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 subscription admins only, 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	Admin only; a guard warns you on unsaved edits if you navigate away

What kinds of widgets exist

A dashboard is a grid of widgets, rendered by the shared widget engine. The platform ships several categories — you pick and configure them in Studio; on the consumer side you just read them:

• 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.

Under the hood. Each widget fetches its own data (getWidgetDetails). Large dashboards can issue dozens of these calls and load slowly — a known performance characteristic. If a consumer dashboard feels sluggish, that’s the cause, not a hang.

The exhaustive widget catalogue, and how you build and configure each one, lives with the builder side — see Shaping the experience.

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 / Data — the classic tabs stay untouched. 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 stored server-side per project, so every browser (and every teammate) sees the same tabs. The card layer behind them is covered in Pages & cards.

Behaviours to know

• Consumers read; builders configure. Everything on a dashboard was defined in Studio (see Shaping the experience). A consumer can switch dashboards, pick a role card, and (if an admin) edit — but the design of the analytics is a build-time act.
• Unsaved-edit guard. If you’re in edit mode and try to leave with unsaved changes, the can-deactivate guard stops you and asks first.
• 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, the server creates an InboxNote that wraps the source document (it remembers the source collection, the document id, and the stage). You design that behaviour when you build the lifecycle — see Taxonomy, lifecycle, tags & events.

The Inbox tab lives in the consumer app (route 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 lifecycle state of the notes 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 note’s title (e.g. “Invoice 4471 needs sign-off”). High-priority notes get a red left border.
• Provenance line — wraps ▸ {collection} · {sourceDocId} · {stage} — tells you exactly which document and which stage produced this item.
• Meta line — who it’s assigned to (if anyone), 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 note 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 / Dismiss are optimistic. When you snooze an open item, it disappears from the Open view immediately, then reappears in Snoozed — you don’t wait for a round-trip.
• The badge count is best-effort. A small count on the Inbox nav entry is a quick estimate, not a guaranteed-exact number.
• Items self-resolve. You don’t mark an Inbox note “done” by hand for normal work — advancing the wrapped document past its human stage resolves the note 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.

1. Open the Inbox tab. Read the “N open” chip and note whether an overdue chip is showing.
2. Flip Scope to Everyone — does the list grow? That tells you whether other people have pending work too.
3. 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.”
4. Click Snooze on one item, then switch Status to Snoozed — confirm it moved there.
5. 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.
• Shaping the experience — build the dashboards, widgets, and Views that feed these surfaces.
• Taxonomy, lifecycle, tags & events — how a lifecycle stage “sends to inbox.”
• Security & governance — how roles gate the Dashboard and other surfaces.