Tasks: your work inbox¶

The single place to find everything waiting on you across Datahub — a glossary term to approve, a contract to review, a workflow step to action — each with its provenance, deadline, and one-click action attached.

Tasks is the one inbox for everything that needs a human decision: every module funnels its work here — the platform's stop pinging me on Slack surface, with provenance, deadlines, and a link to whatever needs doing.

Prioritieslow · normal · high · urgent

ActionsStart · Approve · Reject · Dismiss

Link typessubtask · related · blocked-by

Default roletasks.read · every user

When to choose this¶

See what's on your plate

Open, overdue, and completed-this-week at a glance — then drill into the items that need you today.
Act on what's waiting

Approve or reject a review — glossary term, contract sign-off, metric promotion, workflow step — or acknowledge and dismiss a result.
Decompose or hand off

Break a complex review into subtasks, or mark one task as blocking another.
Trace where it came from

Provenance shows which module raised the task, which workflow it belongs to, and the entity it's about.

When not to reach for Tasks

Tracking engineering work → use Jira / Linear. Tasks is for governance and business decisions, not project-level tickets.
Real-time notification → Tasks is the durable inbox; toasts and emails are the push channel.
Authoring SLA policies → define those in Workflows + Policies. Tasks surfaces the live SLA countdown and runs escalation, but the rules themselves live with the workflow.

How tasks reach you¶

Something happens somewhere in Datahub that needs a person; it becomes a task; the task fans into your one inbox; you act once; the source module is notified and the entity moves forward.

flowchart LR
    G["Glossary term review"] --> WF
    C["Contract sign-off"] --> WF
    M["Metric promotion"] --> WF
    V["Flow version review"] --> WF
    WF["Workflows engine"] --> INBOX
    DIR["Other modules<br/>direct assignments · alert acknowledgements"] --> INBOX
    INBOX(["Your Tasks inbox"]) --> ACT{"You act"}
    ACT -->|"Approve / Reject"| ADV["Workflow advances to the next step"]
    ACT -->|"Acknowledge / Dismiss"| CL["Notification closed"]
    ACT -->|"Custom action"| SRC["Source module handles it"]
    ADV --> FWD["Source module notified ·<br/>entity moves forward"]
    CL --> FWD
    SRC --> FWD
    classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
    class INBOX accent

Figure 1 — Every module funnels work into one inbox. You act once, and the source module is notified so the entity moves forward.

Why teams reach for this

One inbox instead of ten. Every item carries full provenance (which module, which workflow, which entity), a deadline you can sort by, and the action button right there — so nothing sits waiting in a Slack thread that nobody owns.

Where tasks come from¶

Almost every task in your inbox is raised by the Workflows engine: when a workflow starts for an entity — a glossary term submitted for review, a metric promoted, a contract awaiting sign-off, a flow version submitted for approval — the workflow definition specifies which step requires which role group, and the engine creates a task for each reviewer.

Other modules can also create tasks directly through the shared task service — for example, an alert can raise a task that needs acknowledging. Review outcomes (a workflow approved or rejected) no longer arrive as tasks: they're delivered as notifications in the bell (see Notifications vs tasks below), so your inbox stays a list of things that still need a decision. The pattern for a task is always the same:

A module decides "this needs human attention."
It creates a task with a title, description, assignee, action type, and source context.
The task lands in the assignee's inbox; they act; the source module is notified via the action result.

The implication: the inbox is the source of truth for "what's pending" — there is no parallel to-do list hiding in any module's UI.

Notifications vs tasks¶

Not everything that reaches you is a task. Datahub separates work from news:

A task is an actionable work item — it stays in your inbox until you approve, reject, complete, or dismiss it.
A notification is informational — a workflow you started was approved or rejected, or a deadline is approaching. It shows in the notification bell, can be marked read, and auto-expires after 72 hours.

Workflow outcomes used to land as workflow_result tasks you had to acknowledge; they're now delivered as notifications instead, so the inbox only ever holds things that still need a decision. The bell splits into Tasks and Notifications, and its badge counts pending tasks plus unread notifications.

Priority alerts¶

Some in-app alerts are too important to auto-dismiss — a priority toast stays on screen until you close it. Closing one doesn't discard it: it's archived into the same Updates surface as your notifications, under an Alerts heading, where its full detail and any link remain available until you clear it.

How a priority alert differs from a notification

Priority alerts are stored in your browser, not on the server — they don't sync across devices and are cleared when you sign out or your session expires. A notification is the server's record of an outcome; a priority alert is a toast you didn't get to act on in the moment. Removing an archived alert (the trash control) is the one destructive step and asks you to confirm first — a plain close only dismisses.

stateDiagram-v2
    [*] --> Toast: Priority event fires
    Toast --> Toast: Stays on screen (no auto-dismiss)
    Toast --> Archived: You dismiss it
    Archived --> Read: You open / follow its link
    Archived --> [*]: Cleared (Clear read, per-item remove, or sign-out)
    classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600;
    class Archived accent

Figure — a priority alert's lifecycle from toast to archived Alert row.

Concepts¶

Concept	What it is
Task	A unit of work with a title, description, assignee, optional deadline, and an action.
Action type	What the task wants from you — `workflow_step` (approve / reject), `manual` (start / complete / dismiss), or a module-specific custom action.
Priority	low / normal / high / urgent. Affects sort and visual weight.
Source module	Which module raised the task (e.g. workflows, glossary, metric). Tracked for provenance.
Source context	Structured metadata about why — e.g. workflow definition + instance IDs.
Deadline	Optional. A task past deadline is overdue and is prioritised in lists.
Result	After completion, the outcome (e.g. approved / rejected) plus an optional comment.
Task link	A relationship between two tasks: subtask, related, or blocked-by.
Team inbox	A shared queue for tasks assigned to a team rather than a person. Any team member can claim one to own it, or unclaim to hand it back.
Claim / reassign	Claim takes an unassigned team task; reassign moves an open task to another user, and only its holder or a `tasks.admin` may do it (audit-logged, with a required reason).
SLA & escalation	When a workflow carries an SLA policy, the task shows a live countdown; if the deadline passes it can auto-escalate to another reviewer.
Notification	An informational item (workflow outcome, deadline reminder) shown in the bell — not an actionable task. Auto-expires after 72 hours.

The lifecycle¶

stateDiagram-v2
    direction LR
    [*] --> pending: task created
    pending --> in_progress: you start work
    pending --> completed: you act
    pending --> dismissed: you dismiss
    pending --> expired: deadline passes
    in_progress --> completed: you finish
    in_progress --> dismissed: you dismiss
    in_progress --> expired: deadline passes
    completed --> [*]
    dismissed --> [*]
    expired --> [*]
    classDef accent fill:#ff8400,stroke:#e67700,color:#ffffff,font-weight:600
    class pending accent
    class in_progress accent

Figure 2 — A task only moves forward. You can optionally mark it in progress while you work; once completed, dismissed, or expired it can't be reopened.

Forward-only, always auditable

A task transitions only forward: pending → optionally in_progress (when you start work) → completed, dismissed, or expired. Once it reaches a terminal state it cannot be reopened — if the same entity needs action again, Datahub creates a fresh task, so the history stays clean.

What Tasks looks like¶

Surface	Where	What you see
Inbox list	`/tasks`	KPI row (Open, Overdue, Completed this week, Avg resolution), tabs (Open / Completed / Board / Summary / Team), and a table: title, priority, source module, deadline, age. The Open tab includes both pending and in-progress tasks. To filter on the ID, title or description, pick the column from the dashed Add filter button and type. Each active filter shows as a pill, also when a saved view applies it, and Clear all removes every filter at once.
Task detail	`/tasks/{id}`	Three-column layout: tabs (Overview + Linked Tasks) on the left, provenance + what's-waiting + metadata on the right. Inline start / approve / reject / dismiss and reassign actions, plus an SLA countdown when the task carries an SLA policy. A `tasks.admin` can open and act on any task here, not only their own — see Separation of duties.
Team inbox	`/tasks` → Team tab	Unclaimed team tasks plus the ones you've claimed. Claim to take ownership; unclaim to return a task to the queue.
Admin console	Tasks › Administration tab (`/tasks/admin` still redirects there)	Org-wide view of every task (needs `tasks.admin`), per-assignee workload, and bulk approve / dismiss / reassign (up to 50 at once). The Nobody can pick up card counts open tasks that no one can act on: tasks held by someone who is locked, deleted or not a user (what offboarding leaves behind), tasks held by the system account, and tasks no one holds whose group was retired or has no active members. A review is also counted when nobody may decide it: it is held by its own submitter, or by someone who doesn't hold the role that approves it, or it waits in a group where nobody holds that role, or where only its submitter does. An administrator's own review that nobody else could decide is not counted, because the separation-of-duties exception lets them decide it. Show them lists exactly those, as the Assignee → Nobody can pick it up filter, and each row is marked on its holder or its group to say why. Assignee → Unassigned is broader, because it also shows team tasks that are simply waiting to be claimed. A row opens the task detail page, which says the same thing and offers Reassign. Back to Tasks returns you to this tab. When open tasks are waiting on an escalation that failed, a notice above the tabs counts them, and Show failed escalations lists them as the Escalation → Failed, not moved since filter, with the time each one failed. A task leaves that list once someone reassigns, claims or releases it, or a later escalation moves it or confirms its holder.
Sidebar badge	Sidebar → Tasks	Auto-refreshing pending-count badge.
HERC	`/` (home)	Your pending count surfaced on the home page.

Setup — what an admin needs to do once¶

Prereq	Where	Why
Roles	`/rolegroups`	`tasks.read` is included in every authenticated role group by default — every user has an inbox.
Workflow definitions	`/admin/workflows`	Governs which entities create tasks, who reviews, and on which status transitions. See Workflows.
Role groups for reviewers	`/rolegroups`	Workflow steps assign tasks to a role group — make sure reviewer groups exist and have members.

Acting on a task¶

The detail page has the action buttons inline. Which ones appear depends on the task's action type:

Approve / RejectStart / Complete / DismissReassignRotate credentialsCustom action

For workflow_step tasks. Picks the next step in the workflow, with an optional comment.

Approving can be refused when the item cannot go live yet, for example a flow whose ownership contract is not published. Your approval is then not recorded, the task stays open, and a notice above the buttons says why. When the reason can be fixed while the review stays open, you can approve again once it is. Otherwise, Reject with this reason sends it back to the submitter with that reason as the comment.

A flow version with a Save to table step names, above the buttons, every table whose rows each run will replace, linked to that table in the Data Catalog. Approving the flow is the only review those writes get: each run saves the rows as a new version of the table without a review of its own. The name is the one the table had when the flow was submitted, and two tables that share a name each show the start of their id.

Before you decide, the page checks each of those tables as it is now. A table renamed since the flow was submitted shows its current name next to the one it had then. A table that is now archived, or has versioning turned off, gets a warning above Approve, because activating the flow would refuse it: ask the table's owner to put it right, or reject the version with the reason. While the review still waits for you to claim it, the same warning shows above Claim, so you know before you take it on. A table the page cannot read, because you may not open it in the Data Catalog or the read failed, gets a separate warning that it could not be checked, above Approve or Claim in the same way: check it in the Data Catalog, or ask its owner, before you approve.

Once a review is decided, its notice speaks in the past tense: approved or rejected, naming the person who decided it when that is known, or closed without a decision. It still lists the tables the decision covered, with the current name of any that was renamed since, and shows no warnings about them.

For manual and module-created tasks. Start moves the task to in_progress so others can see it's being worked; complete or dismiss closes it with an optional comment.

Hand the task to another user with a required reason. Only the person holding the task, or a tasks.admin, sees this action. It's audit-logged, both people are notified, and — for workflow tasks — the underlying workflow step follows the new assignee.

For rotate_credentials tasks, raised when an integration's or the shared Service Principal's stored secret is rejected. The task opens the credential form directly; saving a new secret and running Test connection closes the task on its own, so you never have to remember to come back and complete it. For a Databricks integration, the scheduled alert sync closes it too, once the integration's own credential signs in on every linked workspace.

If a module defined one, it's handled by the source module that raised the task.

Comments are stored on the task and propagated to the workflow's history, visible on the entity's Activity tab.

Linking tasks¶

Tasks can be linked to each other:

Subtask. A child task that belongs to a parent. Useful for decomposing a complex review.
Related. Bidirectional — "these two tasks share context".
Blocked-by. The source task is blocked until the target completes. Visualised in the what's waiting sidebar.

Links are managed from the Linked Tasks tab on the task detail page.

Team inbox & reassignment¶

Tasks don't have to belong to one person up front.

Team inbox. A task can be raised against a team instead of an individual. It then sits in a shared queue — visible under the Team tab — that any member can pull from:

Claim an unclaimed task to make yourself the assignee (POST /team/{id}/claim).
Unclaim to send it back to the queue (POST /team/{id}/unclaim). Only the person who claimed it — or a tasks.admin — can unclaim, and a task that's already completed, dismissed, or expired can't be returned.

Reassignment. The person holding an open task, or a tasks.admin, can hand it to a different user from the Reassign action on the detail page. Anyone else is told to ask an administrator instead, and a refused attempt is written to the task's activity. A reason is required, the change is written to the audit log, both the old and new assignee are notified, and — for workflow tasks — the underlying workflow step is updated to point at the new reviewer. Admins can reassign anyone's task, in bulk too (up to 50 at a time) from the Administration tab. A task nobody holds waits in its group's inbox for a member to claim it; an admin can also reassign it, and then only the new assignee is notified, since there is no previous holder to tell.

Only someone who can act on the task can receive it. Locked users are not offered in the picker, and a reassign to a user who is locked or deleted is refused with the reason, so the task stays where it was instead of looking handed over. Reassign is the only way to hand a task to someone else. If an escalation's target is locked or deleted, the task stays where it is, and its Activity says whom the escalation named and why it could not hand the task over.

Separation of duties¶

A workflow_step review can't be completed by the person who submitted it — a review is only a review if someone else does it. If you're the submitter, the task shows a blocked state with a Reassign to a reviewer action instead of live Approve/Reject buttons.

The exception: a tasks.admin may complete or claim their own submitted review, but only when there is genuinely no one else's decision to override — the step is unassigned, or assigned to the admin themselves — and nobody else holds the role that approves that kind of item (for items with no such role: no other administrator). The built-in systemuser bootstrap account doesn't count as someone else. If someone else could review it, the admin reassigns it to them instead. A small deployment starts with one person and no second reviewer to hand a review to, so this keeps a fresh install from stranding on its own first approval. If a different person is already the assigned reviewer, the admin cannot use this exemption to override that person's pending decision — they'd need to explicitly reassign the step to themselves first, which is its own audited action shown to both people.

Approving needs the approve role. Each kind of item names the role that approves it (for example glossary.terms.approve for glossary terms). A reviewer who doesn't hold it can still reject the review, but can't approve it: the task page says so, names the groups whose members hold that role (for example Data Owner), and offers Reassign. A review waiting in a group's inbox, which nobody has claimed yet, says instead that it waits for a member of that group. The same rules apply to every way a review is decided: the task page, bulk approval in the admin console, and an AI agent completing the task (whose task read says the same thing before it tries). A review step can't be marked completed through a plain task update, and a decision is either approve or reject: any other result is refused.

A refused attempt is on the record. Trying to decide or claim a review you may not, or approving one the item then refuses, appears in the task's Activity with the reason, although nothing else changed.

What the Activity tab tells you. Every change to a task reads as what happened. A reassignment names who held the task before and after, the reason given, and why nobody could pick it up at that moment (for example, its holder was locked). An escalation names both people and how far past its deadline the task was; one that could not move the task says why. Returning a claimed task to its group's inbox names whose claim it was. People are named even when their account has since been removed, and you do not need permission to view the user list to see them.

Who approved it is who clicked. The item records the person who made the decision as its approver: an administrator deciding someone else's review, a bulk approval, or a team member deciding a review from the group's inbox.

Handing a review to someone who can't decide it. Reassigning, claiming, bulk-reassigning or escalating a review to someone who lacks its approve role (or back to the person who submitted it, while someone else could review it) is allowed, and said right away: the reassign or claim message warns you, bulk reassign lists the reviews concerned, an escalation writes it to the task's activity, and the task page tells everyone but the holder, with Reassign for a tasks.admin.

A role granted while someone is signed in reaches them when they next open or return to Datahub; they don't have to sign out and in again.

sequenceDiagram
    participant U as Submitter
    participant T as Task (workflow_step)
    U->>T: Complete / claim
    alt not the submitter
        T-->>U: Allowed
    else is the submitter
        alt tasks.admin AND (unassigned OR assignee = self)
            T-->>U: Allowed — recorded as a decision with nobody else behind it
        else a different reviewer is already assigned
            T-->>U: Blocked — reassign to a reviewer
        end
    end

Figure 3 — Who may decide a review step you submitted yourself.

Every decision is attributed

Whether it's an ordinary review or the sole-admin exception above, completing, starting, or dismissing a task always records who did it — visible on the task's Activity tab, never anonymised.

SLA & escalation¶

When a task comes from a workflow that has an SLA policy attached, Datahub surfaces the time budget so nothing quietly slips:

The detail page shows the policy name, a colour-coded countdown (green > 50 %, amber 25–50 %, red < 25 % of the budget left) and the point at which it will escalate. The list view carries a compact remaining-time badge.
As the deadline nears, an in-app reminder notification lands in your bell, its urgency rising from warning to critical to overdue.
When a review step has its own deadline and it passes, the reviewer gets a high-priority Overdue task named after the review (Overdue: Review "Revenue alert"). Its description names the workflow, the step and the deadline (Metric definition review · step 'Steward approval' is past its 24h deadline.), and View entity opens the review, where you decide. Older overdue tasks name only the step and don't link to the review.
If the deadline passes on a workflow task that has an escalation rule, Datahub escalates automatically — it reassigns the task to the escalation target defined on the workflow step (a specific user or a role group), stamps the task as escalated, and notifies the new owner.
An escalation fails when an error stops it, or when the step names a target that turns out to be nobody who can take the task: an organisation role with no member who may take it, or a user who doesn't exist. The task stays with the holder who missed its deadline, and that escalation is not tried again. Its Activity tab says so, and the Administration tab counts every open task in that state, so an admin can reassign it by hand.

Who is told

Task admins don't need to keep the Administration tab open. Every 15 minutes Datahub counts the open tasks nobody can act on. The Administration page shows them among the checks that need attention, and everyone who holds tasks.admin gets one bell notification that opens the tab. Failed escalations reach the same people as a single bell notification that counts them and opens the tab with the Escalation → Failed, not moved since filter applied. While it is unread it keeps up with the count, so a cause that persists doesn't ping you every few minutes. When nobody holds tasks.admin, the people in the Administrator organisation role are told instead, or, when there are none, those in the Administrator role group. A notification leaves the bell once nothing is left to fix.

What escalation needs

Auto-escalation only fires for workflow tasks whose step defines an escalation target. Manual tasks, and workflow steps with no escalation rule, still show their deadline and reminders but won't reassign themselves. SLA countdowns likewise depend on a policy being attached to the workflow — a manual task shows only the raw time to its deadline.

Reviews that nobody can decide move up¶

An open review that waits unclaimed in a group that can no longer decide it (the group was switched off, emptied, lost the right, or only the person who submitted the review is left in it) moves up to the next group that can decide it, and finally to Administrators. This runs every 5 minutes, so emptying a group such as Approvers hands its open reviews to Administrators within one run. A group that is no longer on the approval ladder at all (for example a switched-off one) sends its reviews straight to Administrators.

What never moves

A review someone has claimed is never moved. A review already with Administrators stays there, even if they have nobody who can decide it, and stays flagged on the health page. Reviews held by someone who can no longer act, and reviews routed to domain stewards, still need a person to reassign them.

Each move is recorded on the task's Activity tab. The group that receives reviews, and the Administrators, get one bell notice per run with the count (not one per task); it opens your tasks, where the reviews wait under Up for grabs.

Stats panel¶

The list page's KPI row is computed live for you:

KPI	What it counts
Open	All your pending tasks.
Overdue	Pending tasks with a deadline in the past.
Completed this week	Your completed tasks in the last 7 days.
Avg resolution	Mean hours from creation to completion over the last 30 days.

Stewards and managers should look at the open and overdue counts daily; the resolution average is a good proxy for review-throughput health.

Limitations¶

Limit	Why	Workaround
Notifications are in-app only.	We don't push to email by default.	If your tenant needs email, configure via the integration roadmap.
Auto-escalation only fires for workflow tasks with an escalation rule.	Escalation targets are read from the workflow step definition.	For manual tasks, use the deadline + reminders and reassign by hand; add an escalation rule to the workflow step for automatic hand-off.
SLA countdowns need a policy on the workflow.	The SLA budget is resolved from the policy attached to the workflow definition.	Attach an SLA policy in Workflows / Policies; without one, a task shows only the raw time to its deadline.
Once completed, a task can't be reopened.	History stays clean.	Restart the source workflow or create a new task.

Audit & compliance¶

Question a CISO might ask	Where to look
"Who approved this contract?"	Detail page → Result + Result comment. Plus `/admin/audit-log` filtered by `tasks` + entity ID.
"Who reassigned this task, and why?"	Every reassignment and escalation is logged with the old / new assignee and a required reason — see `/admin/audit-log` filtered by `tasks`.
"How long did review X take?"	Detail page → Avg resolution; full history in the audit log.
"Can a user dismiss a task that wasn't theirs?"	No — tasks are scoped to the assignee; the API rejects cross-user actions.
"Did anyone bypass the workflow?"	Workflow steps must complete via tasks; bypass attempts are blocked at the service layer and audit-logged.
"Where do task comments live?"	On the task row + propagated to the workflow's activity log.

Troubleshooting¶

Symptom	Likely cause	Fix
Inbox is empty but I expect a task	Workflow not configured for the entity, or you're not in the reviewer role group.	Check `/admin/workflows` for the entity type; check your role group membership.
Task created for the wrong person	Workflow assigns to the first member of the reviewer role group; that person changed.	Its holder, or a `tasks.admin`, reassigns it from the detail page — the workflow step follows the new assignee.
Approve / Reject buttons greyed out	You don't have the role required for that workflow step.	Have an admin grant the role.
Approve says "Your approval was not recorded"	The item cannot go live yet, for the reason in the notice. Nothing was approved and the review is still open.	Follow the notice: approve again once the reason is fixed if it says that can happen in review, or Reject with this reason to send it back.
Task shows for an entity that no longer exists	Source entity was hard-deleted (rare — most modules archive).	Dismiss the task.
A Rotate credentials task keeps coming back	The secret was replaced with another expired or wrong one — every scheduled run re-detects the same rejection.	Open the integration, paste a freshly generated secret, and confirm Test connection turns green before leaving the page.
Stats KPI is 0 but I see tasks in the list	Stats are scoped to you; the Team tab also shows unclaimed team tasks that aren't yours yet.	Claim a team task to make it count toward your stats.
A review left my team's inbox	Nobody in that group could decide it any more, so it moved up the approval ladder.	Look in the next group up, or with Administrators; the task's Activity tab shows where it went.
Sidebar pending-count badge is stale	The count is cached client-side.	Refresh the page.