---
title: Inbox-First Application
slug: inbox-first-application
kind: ia
summary: The app opens on what needs you, ordered, rather than on a summary of everything — so the first screen is a worklist you can empty, not a dashboard you look at.
problem: >-
  People open the product and land on charts. They then navigate to find the
  work, which means the home screen costs a click and answers a question nobody
  asked. Meanwhile the things that actually need someone are spread across five
  lists and discovered by memory.
family: [orient, act]
principles: [surface-dont-bury, orientation]
status: stable
visibility: public
related:
  - title: Review Queue
    url: /patterns/review-queue
    summary: The single-stream version of the same idea, for one kind of decision.
  - title: Dashboard Disease
    url: /patterns/dashboard-disease
    summary: What an inbox-first app is a reaction against.
---

## The shape

```
  ┌──────────────────────────────────────────────────┐
  │ Needs you                                    7   │  ← the whole home screen
  │ ─────────────────────────────────────────────    │
  │ ⚠ INV-1041 overdue 12 days      chase or write off│
  │ ⚠ JOB-204 handed to you          accept or return │
  │ ● Priya mentioned you on INV-1043                 │
  │ ● 3 expenses awaiting your approval               │
  │ ─────────────────────────────────────────────    │
  │ Nothing else needs you today.                     │
  └──────────────────────────────────────────────────┘
```

The organising claim is that **the top of the application is a worklist**.
Everything else — reports, browsing, configuration — is reachable, but not what
opens.

## When this is the right architecture

- Most people using the product have a **queue-shaped job**: things arrive, they
  act on them, the pile should empty.
- The work spans several record types, so no single list is "the" list.
- Missing something has a cost — a deadline, a customer, a compliance window.
- People use the product most days.

It is the wrong architecture when the primary job is **exploration** (analysis
tools, catalogues, reporting products), or when people arrive with a specific
record in mind and just need to find it — that is a
[search-first](/patterns/global-search) application.

## Why it works

It makes the software's opening statement *"here is what needs you"* rather than
*"here is everything that exists"*. That single change moves the burden of
knowing what to do next from the person to the system, which is the most
valuable thing an internal tool can do for someone doing the same job every day.

It also creates a natural completion state. A dashboard is never finished; an
inbox can be emptied, and being able to finish is a large part of why people
keep coming back to inbox-shaped software.

## What it demands of you

An inbox-first app is a promise, and the promise is expensive:

- **Everything that needs a human must reach the inbox.** One category that does
  not — an email that goes elsewhere, a status nobody surfaces — and people
  learn they still have to check manually, at which point the inbox is an extra
  place to look rather than the only one.
- **Nothing that does not need a human may appear.** The moment it fills with
  informational items, it becomes a feed, and feeds get skimmed.
- **It has to be orderable and emptyable.** If the count never reaches zero, it
  stops being an inbox and becomes a backlog people ignore.

Those three are why this architecture is chosen less often than it should be:
the interface is easy and the discipline is hard.

## The relationship to dashboards

An inbox-first product can still have a dashboard — it is just not the front
door. That is usually the right resolution of the argument: managers want the
numbers, operators want the work, and putting the numbers first serves the
smaller group at the expense of the larger one on every single visit.

## Exemplars

**Front and Intercom** are inbox-first by definition, and demonstrate the
completion effect: agents work to zero, and the product is designed to make that
feel like the point.

**Linear's "My issues"** is an inbox in everything but name, and shows the
cross-record-type version — issues, mentions and reviews in one ordered list.

**GitHub's notifications-as-workflow** is the counter-example that proves the
demand: many teams route it into a separate tool precisely because it fills with
things that do not need a human.

The extractable rule: **an inbox is a claim that this is everything you need to
look at.** Only build one if you are willing to keep that claim true.