Appeals
Receive a public appellant submission, review it privately, communicate status, and record an authorized outcome.
- Audience
- public appellant · moderator · senior reviewer · team lead
- Availability
- free · private beta access
- Maturity
- beta · partial
Last reviewed
On this page
How an appeal moves
The public appeal surface accepts a scoped submission for an enabled server. Authorized staff review the appeal in the server dashboard, record a decision, and expose only the appellant-facing status rather than internal case material.
Confirm appellant and reviewer access
Appellants start at the server-specific public appeal link. Staff start in the selected server's Appeals dashboard or the registered appeal review commands.
- The correct server-specific appeal link and supported appeal type.
- A concise account of the action being appealed and information requested by the form.
- For staff, the permission to review the server's appeal queue and any linked moderation record.
Review, decide, and notify
Submit the appeal
Provide the requested server-scoped information without adding unrelated private data.
Check: The appellant receives a submission result or an error that identifies the invalid field.
Review privately
Authorized staff compare the appeal with the moderation record and only the evidence their role may inspect.
Check: Internal notes and evidence remain inside staff-only surfaces.
Record a decision
Approve, deny, or otherwise resolve the appeal through a supported decision control with a reason.
Check: The decision is attributable and any reversal remains a separate action.
Check public status
Use the public status surface for the outcome exposed to the appellant.
Check: The appellant can see the supported status without receiving internal-only case detail.
Appeal decision examples
The appeal has a server-scoped submission and staff decision, while the public status reveals only the information intended for the appellant.
/appeals list status:Pending/appeals decide id:42 status:Approved note:Your timeout appeal was approved. Staff will verify the reversal separately./appeals decide id:42 status:Escalated note:A senior reviewer will review the case.- Appeal a mute using the server's public link and retain the returned status reference.
- Deny an appeal with a staff-visible reason without copying private evidence into the public response.
- Approve an appeal, then verify that any reversal action completed separately.
Public submission and private review boundaries
| Surface | Viewer | May contain | Must not expose |
|---|---|---|---|
| Public appeal form | Appellant | Server-scoped identifiers and the appellant's statement requested by the form. | Internal staff notes, hidden evidence, unrelated member data, or private reviewer discussion. |
| Public status | Appellant with the supported reference | Submission or decision status and the approved appellant-facing message. | Case packet, reviewer identity details beyond policy, or staff-only reasoning. |
| Appeals queue | Authorized server staff | Appeal summary, linked moderation context, status, dates, and review controls. | Records outside the selected server or evidence the viewer cannot access. |
| Linked Case | Authorized case reviewers | Evidence, discussion, decision, execution, and timeline according to case visibility. | Automatic access for every moderator simply because an appeal exists. |
Appeal states and next actions
| State | Meaning | Staff action | Appellant expectation |
|---|---|---|---|
| Submitted / pending | The appeal was accepted and awaits staff review. | Verify identity, type, linked action, and completeness; claim or route it according to server practice. | Use the status reference; do not submit duplicates merely because review is not immediate. |
| Under review | Authorized staff are evaluating the appeal and linked record. | Keep discussion private and request only necessary additional information. | The final outcome is not yet decided. |
| Escalated | A higher-authority reviewer is needed. | Identify the next owner and preserve the unresolved question. | The appeal remains open unless the public status says otherwise. |
| Approved | The reviewer accepted the appeal outcome. | Verify the separate reversal or corrective action and its final status. | Approval may precede the actual removal of a mute, jail, or ban. |
| Denied | The original action remains after review. | Record the reason and a short public explanation; finalize the review room or Case where supported. | Use the published policy/contact path for any permitted next step. |
| Expired / closed | The workflow reached its configured terminal state without further active review. | Confirm the linked Case and room finalization state. | The public status should state the available outcome without internal details. |
Staff appeal review playbook
Verify the appeal
Confirm selected server, appeal ID/reference, appellant identity, appealed action, submission time, and supported appeal type.
Check: The review is attached to the correct action and person.
Read the original record
Review the action reason, actor, occurrence time, policy basis, linked case, and visible evidence.
Check: The decision does not rely only on the appellant's or moderator's summary.
Assess new information
Separate new evidence, changed circumstances, disagreement with policy, and claims that cannot be verified.
Check: The reviewer states what changed the analysis and what remains uncertain.
Record one decision
Approve, deny, or escalate with an internal reason and an appellant-facing note that omits private staff details.
Check: The appeal has an attributable human outcome.
Verify side effects
For approval, inspect the separate unmute, unjail, unban, or other correction result; for any outcome, verify room/case finalization and notification status.
Check: The record shows what actually happened, not merely what was intended.
Appeal recovery scenarios
Approved but restriction remains
What you see: The appeal shows Approved, but the member is still muted, jailed, or banned.
What may be happening: The decision and reversal are separate; the target state, executor permission, hierarchy, or external Discord call may have blocked the correction.
What to do
- Open the appeal and linked Case.
- Read the reversal/action execution status.
- Verify current Discord state.
- Use the supported retry or matching reversal only when the existing record permits it.
Duplicate appeal
What you see: More than one submission appears to concern the same action.
What may be happening: The appellant may have retried after a delayed response or used different identifiers.
What to do
- Compare server, appellant, action, and timestamps.
- Choose one owning review record.
- Link or close duplicates according to server policy without deleting useful provenance.
- Tell the appellant which reference remains active through the public-safe channel.
Public status and staff view differ
What you see: The internal record changed, but the appellant-facing status appears stale or incomplete.
What may be happening: Publication/notification can be a separate side effect, or the public surface intentionally exposes less detail.
What to do
- Confirm both views use the same server and reference.
- Read the latest internal timeline event.
- Check public-notification/finalization status.
- Escalate a reproducible mismatch without exposing staff-only content.
Keep public and staff views separate
The live server route determines visible statuses and appeal types. Submission does not guarantee approval, a decision does not guarantee that a reversal ran, and public status must not expose staff discussion, unrelated records, or hidden evidence.
Recover a stuck appeal
The result is not what you expected
What you see: The form rejects the submission, the appeal is not in the queue, or the public status does not reflect an expected staff outcome.
What may be happening: The server/type may not support the request, identifiers may be invalid, access may be blocked, or a decision/reversal step may still be pending.
What to do
- Confirm the server-specific URL and appeal type.
- Keep the submission/status reference.
- Staff should inspect the appeal record and separate reversal outcome.
- Escalate through the server's published support path without posting private case material.
Staff should hand off the appeal record and its decision state inside authorized review surfaces. The appellant should rely on the public status and the server's published contact path.
Continue an appeal conversation
Permitted staff can send the appellant a Discord DM or add an internal note. Outbound replies keep queued, accepted, or failed delivery state. Inbound DMs are routed by reply reference and recent appeal context; an ambiguous message may be held as unrouted with candidate appeal IDs until staff resolves it.