# Find blocked work with an actionable scope

Illustrative planning brief; no automatic product import.

Illustrative case: a coordinator needs to review high-priority blocked work, not every incomplete item.

## Decision

Read the filtered set, then inspect each material blocker before requesting help.

## Owned work

- Filter the requested set
  - Owner role: Coordinator
  - Acceptance evidence: The read uses BLOCKED and HIGH only when both constraints were requested.
- Inspect the blocker reason
  - Owner role: Task owner
  - Acceptance evidence: Current detail identifies the specific step that cannot proceed.
- Request the unblock decision
  - Owner role: Decision owner
  - Acceptance evidence: The update names the needed decision and its delivery consequence.

## Workflow

1. Preserve every requested filter and add no hidden restriction.
2. Follow pagination when a complete review is required.
3. Read task detail before assigning a blocker cause or escalation owner.

## Judgment

A task status does not identify its root cause. A single list page is a sample, not all blocked work.


## Illustrative blocker review

Requested set: high-priority blocked tasks in one verified workspace.
Evidence still needed: the blocker condition on each relevant task.
Next action: ask the role able to resolve that condition.


## Illustrative commands (not executed)

```text
teamboost tasks list --status BLOCKED --priority HIGH --org ORGANIZATION_ID --environment production --json --no-input
```


## Workflow questions

### Can I filter by my ownership?

Use --owner me when that constraint belongs to the request; otherwise it would narrow the result incorrectly.

### Does HIGH mean an incident?

No. Follow the actual impact and incident procedure rather than treating priority as proof of an emergency.

## Product connection

The TeamBoost CLI example uses exact task filters to collect blocked work, followed by a separate review of the blocker evidence.

Confirm account availability before adopting this manual outline.