Detail and Manage Surfaces

Use This Dashboard Area Safely

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Detail and Manage Surfaces narrows that work to how to read, edit, verify, and maintain existing report records through the detail and manage pages. 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, Partner admins, and Support leads. 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/detail?id=:incidentId and /reports/manage?id=:incidentId.
• Records or contracts involved: Incident reports, Revisions, and Watchlist entries.
• 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 Detail and Manage Surfaces.
2. Read the current state before changing it: Use /reports/detail?id=:incidentId and /reports/manage?id=:incidentId 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, Revisions, and Watchlist entries 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 report detail page and check the report ID, subject, status, scope, and last-updated information. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the existing facts before acting. Review evidence, revision history, linked people, reminders, watchlist or ban state, and appeal notes before making changes. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Make the smallest factual update. Use manage actions only when your role is allowed to make the change. 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. For each edit, update the exact field, add a reason when the dashboard supports it, then save. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Verify the saved record and history. After saving, reload or revisit the page and confirm the changed field, status, and revision trail are correct. A later reviewer should be able to understand this step from the saved record.
6. Step 6 - Hand off the next responsibility. If you see stale data or dirty-form warnings, stop and resolve that warning before continuing. This leaves a handoff trail another operator can understand.

Detail page

/reports/detail?id=:incidentId is the read-first page. It should answer:

• What happened?
• Who was involved?
• What evidence exists?
• What action was taken?
• What revisions happened?
• What related profile or watchlist context exists?

Use detail before manage. Reading first reduces accidental edits.

Manage page

/reports/manage?id=:incidentId is the edit page. Use it to correct fields, add investigation updates, change status, record action details, and maintain appeal process information.

Permissions

Role	Expected access
Partner admin	Can administer partner report records.
Trust and Safety	Can create and update reports according to ownership and policy rules.
ConOps	Should not receive report-only mutation permissions.
Marketing	Should not receive report-only mutation permissions.
FPH admin	Can handle network-wide report surfaces where policy allows.

Revision history

Every meaningful edit should produce a revision. Revision history helps future reviewers answer:

• Who changed the report?
• When did it change?
• Which fields changed?
• Did the change make the report clearer?
• Did the change support or weaken an action?

Dirty-form protection

The dashboard protects unsaved edits. If you try to leave with unsaved changes, treat the warning seriously. Saving partial or accidental changes can confuse future reviewers.

Common mistakes

• Editing without reading the revision history.
• Updating action fields but leaving status unchanged.
• Removing old context instead of adding a correction.
• Saving a cross-partner recommendation without enough notes.
• Leaving a report open forever after the action is complete.

Verification checklist

• Direct URL load works.
• Refresh keeps the same report loaded.
• Query-only navigation loads the correct report.
• Missing or invalid IDs do not show stale content.
• Save creates a revision.
• Detail page reflects the latest saved data.