Watchlists and Bans

Use This Dashboard Area Safely

Use this guide when a safety, accountability, or follow-up record needs careful handling. In this guide, Watchlists and Bans narrows that work to how local watchlists, shared watchlists, local bans, and network bans work in the report system. 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/watchlists and /reports/bans.
• Records or contracts involved: Watchlist entries, Local bans, Network bans, and Incident reports.
• 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 Watchlists and Bans.
2. Read the current state before changing it: Use /reports/watchlists and /reports/bans 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 Watchlist entries, Local bans, Network bans, and Incident reports 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. Start from the relevant report or person profile, not from memory. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the existing facts before acting. Decide whether the issue calls for local watchlist, shared watchlist, local ban, or network ban review. Pause here and confirm the note is factual, fair, and reviewable.
3. Step 3 - Make the smallest factual update. Check evidence, scope, duration, appeal path, and affected community before applying any restriction. 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 action, reason, status, review date, and appeal information. The next action should still protect privacy, evidence, and due process.
5. Step 5 - Verify the saved record and history. Save and confirm the person profile, report detail, and list views show the same restriction state. A later reviewer should be able to understand this step from the saved record.
6. Step 6 - Hand off the next responsibility. Notify only the people who need to know, using the approved communication path. This leaves a handoff trail another operator can understand.

Watchlist meaning

A watchlist entry is a staff attention marker. It says: “When this person appears, staff should check context before acting normally.”

It is not always a ban. It can mean monitor, verify identity, ask senior staff, or review a report before allowing a role.

Ban meaning

A ban is a restriction. It says the person is not allowed in a scoped space, event, or network while the ban applies.

Local watchlist vs shared watchlist

Type	Meaning	Who sees it
Local watchlist	Your partner should pay attention to this person.	Your partner’s permitted staff.
Shared network watchlist	Multiple partners need safety context.	Trusted network partners and FPH admins.

Local ban vs network ban

Type	Scope	Use when
Local event ban	One event or partner event set.	The risk is real but local to your event/community.
Local community ban	Partner-level restriction.	The partner needs a broader restriction.
Network ban	Shared FPH partner network.	The risk is serious enough that other partners need to act too.

Dashboard surfaces

• /reports/watchlists shows local and shared watchlist entries.
• /reports/bans shows ban records and ban management actions.
• Report detail/manage pages can link enforcement actions back to the source incident report.

Common mistakes

• Using watchlist as a secret punishment.
• Creating a ban without a source report.
• Forgetting expiry or review date for temporary restrictions.
• Applying network scope when local scope is enough.
• Removing a ban without recording why.

Verification checklist

• Entry links to a source report where possible.
• Scope is correct.
• Expiry/review date is recorded when needed.
• Action notes explain the decision.
• Appeal process is documented for restrictive actions.
• Shared entries are visible where expected and not visible where not permitted.