How Do I Clear a Pending Task Backlog in Dave by voolama?

Summary

The steps

1. 1

   Open the Task Inbox and filter to pending

   The Task Inbox is the starting point for every task in Dave by voolama (hellodave.ai). It shows all tasks assigned across your tenant. Sourced from the tasks help documentation, DEV v0.11.0, confirmed against content_orchestrator main at commit ddb945f, 2026-08-30.

   Navigate to Tasks in the sidebar. The page heading reads Task Inbox. If Tasks is not visible in the sidebar, your account lacks the Admin or Use role. See Why Can't I See Agents, Workflows, or Other Sections in Dave by voolama? for the role assignment path.

   The task table displays five columns: Type (the task type, linked to the task detail page), Status (a colour-coded badge), Instance (a truncated instance ID linking to the parent workflow instance), Assignee (the user ID of the assigned person, or a dash if unassigned), and Due (the due date if set, or a dash). Verify independently: open the Task Inbox and confirm these five column headers are present in the UI. No vendor trust required.

   Do this

   • Navigate to Tasks in the sidebar.
   • Use the status filter dropdown in the top-right corner. Select pending.
   • The list now shows only tasks waiting for action.
   • If the list is empty after filtering to pending, set the filter to All Statuses. If still empty, no workflow instances have reached an interaction or review node yet.

   Example

   A team lead opens the Task Inbox and sees 14 tasks. The status filter is set to All Statuses. Switching to pending shows 9 tasks. The other 5 are completed or cancelled and need no action. The 9 pending tasks are the backlog to clear.

   Best practice

   The tasks help documentation states: "Use status filters to focus. Filter to pending to see tasks that need your attention, or completed to review past decisions." Always filter to pending before starting a backlog session. Reviewing completed tasks alongside pending ones adds noise and slows throughput.

2. 2

   Prioritise by due date, then by age

   Not all pending tasks are equally urgent. The tasks help documentation states: "Watch for due dates. Tasks with a due date may time out and fail if not completed in time. Prioritize tasks approaching their deadline." A failed task means the parent workflow instance cannot continue on its current path. Sourced from the tasks help documentation, DEV v0.11.0, confirmed 2026-08-30.

   The Due column in the task table shows the due date for each task, or a dash if no deadline is set. The tasks help documentation defines Timeout as: "An optional timestamp after which the task may be automatically failed or escalated by the system." A task approaching its Timeout is higher priority than a task approaching its Due date, because a Timeout failure is system-enforced. Verify: open the task detail page and check whether a Timeout field is present alongside the Due field. Both are visible directly in the UI.

   Do this

   • In the pending task list, look at the Due column. Identify any tasks with a due date that is today or tomorrow.
   • Work those tasks first, in order of earliest due date.
   • For tasks with no due date (showing a dash), work them oldest first.
   • If a task has a Timeout field on its detail page, treat it as higher priority than its Due date.

   Example

   Of 9 pending tasks, 2 show a due date of today. 3 show a due date of next week. 4 show a dash. The correct order: complete the 2 due today first, then the 3 due next week, then the 4 with no due date in any order.

   Best practice

   The tasks help documentation states: "Check your Task Inbox regularly. Pending tasks block workflow progress." A daily check at the start of each working day prevents the backlog from accumulating. If the Pending Tasks count on the Dashboard is consistently above 10 at the start of each day, the team has a capacity problem: ask an Admin to assign additional Use-role users at Admin, then Settings, then Users and Roles.

3. 3

   Read the payload before deciding

   Every task in Dave by voolama (hellodave.ai) carries a Payload: a JSON object passed from the workflow to the task, containing the data the assignee needs to make a decision. The tasks help documentation states: "Review the payload carefully. It contains the content or data that needs your review." Sourced from the tasks help documentation, DEV v0.11.0, confirmed 2026-08-30.

   Click the task's Type link in the task list to open the task detail page. The Payload section shows the JSON data. Read it before clicking any decision button. If the Payload section shows an empty object {}, the workflow node did not pass any data. The tasks help documentation states this is a workflow configuration issue, not a task issue. Verify: an empty payload is independently identifiable by any reviewer because the Payload section displays {} directly in the UI. No vendor trust required.

   Do this

   • Click the Type link for the first task in your prioritised list.
   • Read the three metadata cards: Instance, Assignee, and Due.
   • Read the Payload section fully before deciding.
   • If the payload is empty ({}), do not click Approve. Contact the workflow creator to fix the node configuration.

   Example

   A human_review task opens with a Payload containing a JSON object with a key called draftContent holding a 400-word article draft. The reviewer reads the draft, identifies a factual error, and decides to click Request Changes rather than Approve. Without reading the payload, the reviewer would have no basis for the decision.

   Best practice

   The tasks help documentation states: "Make sure you understand what you are approving or rejecting before clicking a decision button." The Submitted Result section (visible after completion) records your decision and comment but not a snapshot of the payload at decision time: the payload is your only opportunity to review the content before acting.

4. 4

   Complete the task with the correct decision and a comment

   Four task types exist in Dave by voolama (hellodave.ai): user_interaction, human_review, agent_review, and safety_check. Sourced from the tasks help documentation, DEV v0.11.0, confirmed 2026-08-30.

   For user_interaction tasks: the workflow is requesting input or content from you. Click Approve to submit your response and advance the workflow.

   For human_review, agent_review, and safety_check tasks: the tasks help documentation states: "Your decision (Approve, Reject, Request Changes) determines which outgoing edge the workflow follows from the review node."

   • Approve (green): the content meets requirements and should proceed.
   • Reject (red): the content is unacceptable and the workflow should not continue on the current path.
   • Request Changes (outlined): the content needs revision before it can be approved.

   Verify independently: after submitting a decision, navigate to the parent instance detail page. The instance's status and tasks table both update to reflect the completed task and the next node. No vendor trust required.

   Do this

   • Scroll to the decision panel at the bottom of the task detail page. It appears only for tasks in pending or in_progress status.
   • For a user_interaction task: type any relevant context in the Comment field. Click Approve.
   • For a review task: choose Approve, Reject, or Request Changes. Add a comment on every Reject and Request Changes decision.
   • After submitting, the task status badge changes to completed (green) and the Submitted Result section appears.

   Example

   A safety_check task payload contains AI-generated content that includes a potentially harmful instruction. The reviewer types 'Content includes step-by-step instructions for bypassing a security control. Rejecting per safety policy.' in the Comment field and clicks Reject. The workflow follows the Reject edge. Any Admin can verify: navigate to Admin, then Settings, then Audit Log and filter by the instance ID. The rejection event is recorded with the reviewer's user ID and the comment text. No vendor trust required.

   Best practice

   The tasks help documentation states: "Use comments to document your decisions. Even a brief note explaining why you rejected or requested changes helps workflow owners and other reviewers understand the history." Task decisions support SOC 2 CC6.1 and GDPR Article 30 when those standards are active. NIST SP 800-53 Rev 5 AU-6 (Audit Review, section 6a) requires review of audit records for unusual activity: a comment naming the specific reason for rejection makes that review faster. Verify: any Admin can navigate to Admin, then Settings, then Audit Log and confirm the comment text is recorded alongside the decision event. No vendor trust required.

5. 5

   Handle the three failure scenarios

   Three failure scenarios are documented in the tasks help documentation, DEV v0.11.0, confirmed 2026-08-30. Each is independently verifiable without vendor assistance.

   Scenario 1: Decision buttons are missing. The tasks help documentation states: "Decision buttons only appear for tasks in pending or in_progress status." Check the status badge colour directly in the UI: amber (pending), blue (in_progress), green (completed), red (failed), gray (cancelled). If completed, failed, or cancelled, the task is no longer actionable. No vendor trust required.

   Scenario 2: Submission fails with 'Failed to submit decision' error. Three causes: a network error, the task was completed by another user, or the parent instance is no longer in a state that accepts task submissions. Fix: refresh the page. If still pending or in_progress, try submitting again. If the error persists, click the Instance ID link and check the parent instance status. Verify: the parent instance status is visible on the instance detail page without any additional vendor tools.

   Scenario 3: No tasks appear in the Task Inbox. Two causes: no workflow instances have reached an interaction or review node yet, or the current status filter is hiding existing tasks. Fix: set the status filter to All Statuses. If still empty, navigate to Instances and confirm at least one instance is in running status. Verify: the Instances list is accessible to Admin and Use roles at the Instances sidebar item.

   Do this

   • Missing decision buttons: check the status badge colour. Amber or blue: refresh the page. Green, red, or gray: the task is done.
   • Submission error: refresh the page. Retry. If the error persists: click the Instance ID link and check the parent instance status.
   • Empty Task Inbox: set the status filter to All Statuses. If still empty: navigate to Instances and confirm at least one instance is in running status.

   Example

   A reviewer clicks Approve on a human_review task and sees 'Failed to submit decision.' They refresh the page. The status badge now shows completed (green). Another reviewer submitted the same task two seconds earlier. The workflow has already advanced. Verify: navigate to the parent instance detail page and confirm the instance has moved past the review node. No vendor trust required.

   Best practice

   For teams with multiple reviewers working the same Task Inbox simultaneously, the 'Failed to submit decision' error is expected when two reviewers open the same task and one submits first. The tasks help documentation does not document a task-locking mechanism. The correct response is to refresh and confirm the task is completed (green badge), then move to the next pending task.

What this guide does not cover