Inbox

A Search (X-02) with its own treatment: every result set is a canned search, and there is no filter rail. The app bar tabs (Active · Completed · Delegated) are the canned searches. Saved searches reuse the same two panes: a task list on the left and the selected task on the right. Pagination or Load more sits under the list. Saved searches are a menu button in the toolbar; the .qf-saved-views chip row stays in the markup but is hidden.

The right pane has two presentations. Which one shows is a user setting, not a control on the page: Open inbox tasks as in the identity menu, beside the theme, sets .qf-inbox[data-view]. Task view is task-centric. Its header is the task (process, step, status and the object it is on) on a tinted band, with the task’s facts under it: Due, Received, Assigned to, Working user and Last action. The v2 API edits none of those facts, so they are read-only; the header’s buttons are the state changes it does allow, Put on hold and Put back. The body groups the rest into cards: Instructions, the object (its fields and initiating document) and the object’s notes. The footer completes the task with an outcome, the default one filled and one with a note in More, or offers Work task while the task waits in a queue. Object view is how the product works today: the object is the header, then its fields and its activity tabs (Active Task · Documents · Notes · Timeline · Workflow · Related) opened on Active Task, where the task is worked through Instructions, Completion Options, Note and Submit.

Everything a task shows comes from the v2 task (status, dueDate and daysOverUnder, startDate, assigneeId, workingUserId, processName, lastAction, instructions, initiatingDocumentVSId, availableCompleteTaskActions) or from a lookup it names: user and group labels, the object’s label and fields, and the object’s notes, which have a subject and a date but no author. The API has no priority, sender, unread state, step position or delegation, so the Inbox shows none. List rows carry only list data: the task name, process and object type, due state and status.

The Inbox is the two-pane case of the rule that every result resolves to an object: selecting a task in the left list shows that task’s .qf-object[data-presentation="pane"] on the right, and the row it came from carries aria-selected="true" (aria-current="true" is styled the same way, for two-pane views whose list is not a listbox). The right pane is not a bespoke reader: it is the ObjectDisplay block with the Inbox’s own sections composed into its __body. A view that is not two-pane opens the same object as a window instead — see ObjectDisplay.

The full-screen page is inbox.html, inside the app shell and styled by css/classic/composites/inbox.css. The specimens below are copied from inbox.html by bun scripts/design-pages/build-composite-pages.mjs — edit that file, not this one; --check fails when they drift.

Guidance

When to use

• Use it as the home for the user's workflow tasks: a task list on the left and the selected task on the right.
• Use it when result sets are canned searches (Active, Completed, Delegated) chosen from the app bar tabs, plus saved searches.
• Use task view when users work task by task: instructions, the object, its notes and an outcome to complete.
• Use object view when users work from the object: its fields and activity tabs, with the task under Active Task.

When to consider something else

• Use Search when users need free filtering with a filter rail or other result views. See Search.
• Use the NotificationCenter for events the user only needs to read. See NotificationCenter.
• Use a DataGrid when users process many tasks in bulk by column rather than one at a time. See DataGrid.
• Use OverlaySystem windows when users need several tasks or objects open side by side. See OverlaySystem.

Usability

Accessibility

Keyboard

Roles and names

• The task list is <ul role="listbox" aria-label="Active tasks"> with role="option" rows; aria-selected="true" marks the task in the right pane and roving tabindex follows it.
• The detail is <article class="qf-object" data-presentation="pane" aria-labelledby> pointing at its <h2 class="qf-object__label">; body sections use <h3> headings.
• The toolbar is role="toolbar" with an aria-label naming the search; the query is labeled Search tasks.
• Saved searches are menuitemradio items with aria-checked.
• Pagination is <nav class="qf-pagination" aria-label="Task pages">.

Focus

• Selecting a task does not move focus into the detail pane; users Tab or use a landmark key to reach it.
• After completing a task, move focus to the next task in the list and announce the result.
• The header's Open task button has no behavior in the reference; if the binding opens a window from it, closing that window must return focus to the button.

Other requirements

• Announce the selected task's title when the pane changes, or rely on the option's own name being read on selection (4.1.3).
• Overdue and due-soon states carry text and an icon, so they are not color only (1.4.1).
• The two panes must stack or reflow at 320 CSS pixels (1.4.10).
• Task rows and footer buttons must meet 24 by 24 CSS pixels (2.5.8).

Test your implementation too. This guidance covers the element as specified here. How a screen composes it (labels, order, announcements) still needs its own keyboard and screen reader check.

Accessibility tests

Passed the gate (run 358b316 on 2026-10-22): no finding in any theme. Awaiting a person’s approval of the checklist below.

Approving. When the checklist passes on the checked run, record it with bun run a11y:approve -- inbox --by "Your name" and commit a11y/approvals.json with the rebuilt pages. All test status

Package

Consumers link one stylesheet, css/classic/index.css, which includes every element. The files below are where this element is defined.

Latest updates

All release notes