What a Camunda 8 task inbox needs to do

The inbox is the process, for most people

Process designers see BPMN diagrams. Everyone else sees a list of tasks. For a claims handler, a nurse or a back-office clerk, the inbox is the process: if it is slow, confusing or loses their work, the process is slow, confusing and loses work.

In Camunda 8, a user task is a step where the engine waits for a person. The engine knows who the task is for (an assignee, or candidate users and groups), when it is due, and which form belongs to it. The inbox is the application that turns that into a working day.

Sort by what is due, not by when it arrived

A list sorted by creation date hides the task that is late behind twenty that are not. Camunda 8 user tasks can carry a due date and a follow-up date, set in the BPMN model or from process data. A good inbox uses them:

• Late tasks first, impossible to miss.
• Due today next.
• This week after that.
• To claim: tasks offered to a group that nobody has taken yet.

Lanes like these answer the question people actually ask in the morning: what do I have to do first?

Show only what each person may work on

Candidate groups decide who may claim a task. The inbox must respect them: a credit committee task should not appear for the whole bank. It must also show clearly what is already claimed and by whom, so two people do not work on the same case.

Dispatchers need the opposite view: every open task under the person who holds it, with the unassigned ones first, so they can rebalance work in a click when someone is away.

Open the task with its context

A form on its own is rarely enough. The person completing a task needs:

• the data that came in with the case (the original request, earlier answers);
• the history of the case: who did what before them;
• what happens next once they submit.

Without that context, people go looking for it in emails and spreadsheets, and the process slows down outside the tool.

Never lose what someone typed

Long forms get interrupted. A tab closes, a session expires, a phone rings. An inbox that throws away half an hour of typing teaches people to fill forms in a text editor first. Two habits fix this:

• Drafts: what someone types is kept and restored when the form opens again.
• Prefill: later forms start from the answers given in earlier steps, so nobody types the same address three times.

Tell people when work arrives

Nobody should have to refresh an inbox to find out a task has arrived. An in-app notification and an email when a task is assigned or offered keep work moving, as long as people can trust that each alert matters.

Checklist

• Tasks sorted by deadline, with late ones on top
• Candidate groups respected; claims visible
• A workload view for dispatchers
• Case data and history next to the form
• Drafts and prefill
• Notifications for new tasks

In Bridge

The Bridge task inbox sorts tasks into Late, Due today, This week and To claim. Each task opens with its form, its context and the history of the case. A task given to a group in BPMN only appears for people whose role carries that group, and what someone types is saved as a draft and restored when the form opens again; later forms are prefilled from earlier steps.

Dispatchers see every open task under the person who holds it, unassigned first, and assign in a click. New tasks arrive with an in-app notification and an email alert.