Overview and List Surfaces

Use This Dashboard Area Safely

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Overview and List Surfaces narrows that work to how to use the reports overview, all reports, my reports, and legacy mine route without losing context. Because this is a surfaces page, read it as part of the Report System learning path rather than as an isolated checklist.

A report is a written memory of something important. The goal is to protect people, keep facts clear, and leave enough context for future reviewers. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What The Screen Controls

This page explains a specific surface. Treat every button, field, filter, and table as a way to view or change real records, not just as a visual layout. The intended readers are Trust and Safety staff and Partner admins. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /reports, /reports/all, /reports/my-reports, and /reports/mine.
• Records or contracts involved: Incident reports and Report list filters.
• Main care point: Watch for incomplete facts, unfair wording, privacy exposure, or a decision that another reviewer cannot understand later.
• Proof worth keeping: report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner.

Read The Screen From Top To Bottom

1. Confirm you are on the right event, report, route, or file: Begin by naming the Report System situation, the owner, and the exact item involved in Overview and List Surfaces.
2. Read the current state before changing it: Use /reports, /reports/all, /reports/my-reports, and /reports/mine to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Use the smallest action that matches the task: Keep Incident reports and Report list filters in view so the work stays tied to the records or contracts it can affect.
4. Check the list, detail view, history, or public page afterward: Before handing off, save proof such as report ID, saved status, revision history, person profile, evidence note, reminder, reviewer decision, and handoff owner so another reviewer can understand the facts without relying on memory.

Before You Leave The Screen

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on people, privacy, fairness, evidence, and the trustworthiness of the record.
3. Proof is findable: The handoff points to evidence that another reviewer can understand the facts without relying on memory.

End-to-end operator runbook

Use this numbered runbook when you need to operate this area without getting stuck. Read the purpose of each step, do the action in order, and use the final sentence as the checkpoint before continuing.

1. Step 1 - Identify the report and scope. Open the relevant report list: overview, all reports, my reports, or legacy mine route. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the existing facts before acting. Choose filters for status, owner, severity, scope, or age before opening individual records. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Make the smallest factual update. Sort or scan for urgent items first: new severe reports, overdue reminders, appeals, and unresolved safety risks. This keeps the report useful to the next reviewer instead of only to the person writing it.
4. Step 4 - Check fairness, privacy, and risk. Open each record from the list, complete the required review or update, then return to the list. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Verify the saved record and history. Refresh the list and confirm the record moved, disappeared, or changed status only when expected. A later reviewer should be able to understand this step from the saved record.
6. Step 6 - Hand off the next responsibility. If a list looks empty, check filters and permissions before assuming there are no reports. This leaves a handoff trail another operator can understand.

Reports overview

/reports is the starting point for report work. It should help staff understand current report activity, open important queues, and move into the correct surface.

Use it to answer:

• Are there new or triage reports?
• Are there unresolved serious cases?
• Which report area should I open next?
• Do I need all reports, my reports, bans, watchlists, appeals, or profiles?

All reports

/reports/all lists reports visible to the current user’s role and partner scope. It is for broader review, admin checks, and finding reports that are not personally assigned.

My reports

/reports/my-reports focuses on records connected to the current user. Use it for daily follow-up, open tasks, and checking whether your own filed reports need updates.

Legacy mine route

/reports/mine is retained for compatibility with older links or dashboard navigation. Treat it as the legacy path for the same “my reports” concept unless the dashboard implementation says otherwise.

List workflow

1. Action 1. Start at /reports. Pause long enough to confirm the record says only what is known.
2. Action 2. Open the right list for your job. Check the saved value before adding more context.
3. Action 3. Filter or scan by status, severity, subject, date, and partner scope. Use the report history as the source of truth before continuing.
4. Action 4. Open detail before editing. Pause long enough to confirm the record says only what is known.
5. Action 5. Use manage only when an actual update is needed. Check the saved value before adding more context.

Common mistakes

• Assuming a missing report does not exist when it may be outside your scope.
• Editing from a list context before reading the full detail page.
• Ignoring old triage reports because they are no longer at the top.
• Treating legacy /reports/mine links as broken instead of compatibility links.

Verification checklist

• Each list route loads directly and through navigation.
• Filters or visible state do not leak stale reports after partner scope changes.
• Rows link to the correct detail ID.
• Empty states explain what to do next.