Appeals and Cross-Bans

Use This Dashboard Area Safely

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Appeals and Cross-Bans narrows that work to how cross-community ban requests and network ban appeals work, and why appeal handling is part of fairness. 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 Partner admins and FPH administrators. 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/cross-bans, /reports/network-ban-appeal?entryId=:watchlistEntryId, and /reports/ban-appeals.
• Records or contracts involved: Cross-ban requests, Network ban appeals, Appeal 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 Appeals and Cross-Bans.
2. Read the current state before changing it: Use /reports/cross-bans, /reports/network-ban-appeal?entryId=:watchlistEntryId, and /reports/ban-appeals 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 Cross-ban requests, Network ban appeals, Appeal 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 appeal or cross-community request from its list or linked report. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the existing facts before acting. Read the original decision, evidence, scope, and appeal statement before deciding anything. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Make the smallest factual update. Check whether the appeal changes facts, proportionality, duration, or community scope. 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. Record the decision, reason, reviewer, and any changed restrictions. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Verify the saved record and history. Save and confirm linked report, profile, watchlist, or ban records now match the decision. A later reviewer should be able to understand this step from the saved record.
6. Step 6 - Hand off the next responsibility. Communicate the decision using clear wording and the correct audience. This leaves a handoff trail another operator can understand.

Cross-community ban requests

/reports/cross-bans is the page for cross-community ban recommendations. A partner may recommend that an enforcement action should affect other partners, not only their own event.

Use this only when other partners have a real safety reason to know.

Network ban appeals

/reports/network-ban-appeal?entryId=:watchlistEntryId lets an appeal be submitted for a network ban entry. Appeals are not an annoyance. They are the system’s way to check whether the record is still fair, accurate, and proportionate.

Appeal review

/reports/ban-appeals is the review surface for permitted reviewers, especially FPH administrators. It should show appeal context, current entry information, appeal text, prior decisions, and action controls where allowed.

Good appeal decision notes

Good notes answer:

• What did the appellant claim?
• What record or evidence was reviewed?
• Was anything wrong, outdated, or missing?
• What decision was made?
• What happens next?

Common mistakes

• Treating every appeal as bad faith.
• Sharing private victim details unnecessarily.
• Approving or denying without checking the source report.
• Forgetting to update the underlying watchlist or ban state when the appeal decision requires it.
• Letting partner admins perform FPH-only network decisions.

Verification checklist

• Cross-ban requests show the correct source partner and report context.
• Partner admin cannot perform FPH-only network decisions.
• FPH admin can review and decide where policy permits.
• Appeal submission, edit/resubmit, deny, and approve states reload correctly.
• Appeal revisions are preserved.