Status reports vs exception reports: choosing the right workflow
Compare status reports and exception reports using the same source packet, distinct useful outputs, and a reviewable Righthand brief.
Quick answer
Use a status report when stakeholders need a balanced picture of progress. Use an exception report when an owner needs to act on deviations from an agreed threshold.
The practical test is the question your reviewer needs answered. Start both workflows from the same dated input packet, then judge the usefulness of their different outputs. Righthand can help prepare either draft from owner-provided records or an approved read view; the reviewer retains authority over decisions and external actions.
Compare the same input
Use this shared packet: A project's milestone list, task status export, dependency notes, baseline dates, and owner-approved exception thresholds at one cutoff. Keep stable identifiers, source links, and a cutoff so another person can reproduce the comparison. Missing information stays explicitly unknown rather than becoming an invented fact.
| Workflow | Useful output | Review owner |
|---|---|---|
| Status reports | Progress, completed milestones, next work, and overall risks | The project manager |
| Exception reports | Only threshold breaches, their impact, responsible owners, and proposed responses | The project manager |
Asana describes project status updates as repeatable summaries that can highlight completed milestones and overdue work. The official Asana project status updates reference supports this specific distinction; the rest of the example is a suggested operating practice, not a universal provider feature or requirement.
Illustrative worked comparison
Illustratively, four milestones are complete and one supplier task is two days late. The status report shows all five and explains the overall plan. If the agreed escalation threshold is one day, the exception report isolates the supplier delay and the specific decision needed.
Evaluate both drafts against that packet before introducing more sources. Changing the input halfway through makes it difficult to tell whether the workflow or newly available evidence caused the difference. Keep assumptions next to the conclusions they affect, and make the next requested decision visible to the reviewer.
Delegation brief for both workflows
Use only the approved input packet described above, with its recorded cutoff. First, draft a status report covering progress, next milestones, dependencies, and uncertainties. Separately, draft an exception report limited to breaches of the supplied thresholds, with evidence and a response owner. Use America/Los_Angeles for the review deadline and preserve the original dates and time zones. Run this comparison once and return both drafts in this conversation by Friday at 3 PM Pacific for The project manager to review. Include source IDs, missing inputs, assumptions, and a next step with an owner. Do not send messages, modify records, make purchases, or approve decisions. If access is unavailable or the packet contradicts itself, report that limitation before completing the affected section.
Check the result
Recompute each exception against the supplied baseline. Ensure the status report includes useful completed work while the exception report excludes items that remain within tolerance.
A completed draft is evidence of preparation, not evidence that its recommended action occurred. The owner should accept or revise the outputs before any separate execution request. For a recurring version, specify the next input window, review deadline, and destination rather than reusing an old snapshot silently.
Failure and recovery
Missing baseline dates can turn every late-looking task into an exception. Ask for the accepted baseline, retain an unknown category, and rerun only the threshold check after clarification.
An exception threshold is a team decision, not a rule inferred from the loudest message. Publishing reports or changing schedules requires separate authority.
FAQ
Should I use both workflows?
Use both when the outputs answer distinct questions that are currently useful. Start with the smaller deliverable when review capacity is limited; preserve the shared source packet so the second can be prepared later without guessing.
Does delegation require a native integration?
An approved export or owner-prepared packet can support the first comparison. A live read or later write requires verified connection tools and the appropriate permission; a catalog entry alone does not establish either.
Use Righthand Docs for delegation and permission guidance, check available integrations, and review Pricing before expanding the task.