Staff notes
Add attributable server-scoped context, manage supported deletion, and keep observations separate from source facts.
- Audience
- moderator · senior reviewer · team lead
- Availability
- premium preview · private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
Write notes another moderator can use
Staff notes add human-authored context to a member inside one server. Each note is attributable to its author and time; deletion is supported for the author or staff with note-management permission.
Confirm the note audience first
Creating a note requires notes.create. Deleting someone else's note requires notes.manage; the author can delete their own supported note. The current surface does not promise in-place editing.
Open Staff Notes or the member's note surface, select the verified member, and write a concise server-policy-relevant observation.
- The correct member and selected server.
- A legitimate moderation purpose and visibility-appropriate wording.
- A source reference when the note makes a factual claim.
Add, read, and preserve context
Choose the member
Search and verify the Discord ID before opening the note form.
Check: The note will attach to the intended server-scoped member.
Write attributable context
Separate observation, source fact, interpretation, and requested follow-up in plain language.
Check: A later reviewer can understand who wrote what and why.
Save and verify
Submit once, then confirm the author, timestamp, member, and rendered text.
Check: The new note appears in the authorized note list.
Correct the note
If correction is needed, add a clarifying note and delete the obsolete note only when authorized.
Check: The team does not rely on an undocumented in-place edit workflow.
Useful staff-note examples
Authorized staff see concise, attributable member context that remains distinguishable from underlying records and evidence.
- Note that a member requested follow-up, then link the relevant case number.
- Label an unverified report as unverified instead of presenting it as fact.
- Add a correction note before deleting an obsolete note when audit context matters.
Write notes as attributable staff context
| Part | Include | Avoid |
|---|---|---|
| Observation | What the author directly saw or was told. | Presenting rumor as fact. |
| Source | Case, record, message, or timestamp when available. | Pasting restricted evidence into the note. |
| Interpretation | Clearly labeled staff assessment. | Insults, diagnoses, or unsupported motive claims. |
| Action/follow-up | What staff did and what remains. | Vague “watch this user” instructions. |
| Uncertainty | What is unverified, missing, or disputed. | Hiding uncertainty to make the note sound conclusive. |
| Quality | Example |
|---|---|
| Useful | “Member reported unwanted DMs on July 17. Screenshot not yet verified. Case #104 created; senior reviewer requested original message link.” |
| Useful correction | “Correction to July 16 note: the message was in #support, not #general. Case #104 source link updated.” |
| Too vague | “Bad attitude. Keep an eye on them.” |
| Too sensitive | “Copied full senior-only evidence into a general staff note.” |
Create, review, correct, and delete notes
Verify the member
Confirm server and numeric user ID.
Check: The note attaches to the correct profile.
Choose the audience
Confirm the note surface and viewer permissions.
Check: Sensitive context is not widened.
Write and save once
Use concise source-aware language and wait for the saved result.
Check: An attributable note appears with author/time.
Refresh before repeating
Confirm the note is present before submitting again.
Check: Duplicate notes are avoided.
Correct transparently
Add a correction/clarification and delete an obsolete note only when authorized.
Check: The team understands what changed.
Keep notes within their purpose
- Do not use notes as a substitute for a Case when evidence, decision, or execution must be audited.
- Do not copy another server’s private information into this server’s profile.
- Do not store credentials, payment data, medical details, or unrelated personal information.
- Do not convert deterministic analytics or imported labels into factual claims.
- Do not expose senior-only evidence to a broader notes audience.
- Do not use a note to bypass an appeal, Ban Review, or action permission.
Recover from a wrong or duplicated note
A note was added to the wrong member
What you see: The text is accurate but attached to the wrong server-scoped profile.
What may be happening: A similar display name, stale profile drawer, or server switch caused an identity error.
What to do
- Record the exact wrong note ID/profile without copying its content elsewhere.
- Add the correct note to the intended member only if still needed.
- Have the author or notes.manage staff delete the wrong note.
- Document the correction in the relevant Case when the mistake affected a decision.
A save looked unsuccessful but the note exists twice
What you see: The note list contains duplicates.
What may be happening: The first request completed while the client response was delayed or the operator retried before refreshing.
What to do
- Refresh the list and compare author/timestamps.
- Keep the most complete intended note.
- Delete the duplicate when authorized.
- Do not create a third note to explain the duplication unless audit context requires it.
Keep private notes inside their boundary
Deletion removes the supported note from the current view and should not be described as a universal erasure guarantee. The surface documents creation and permission-aware deletion, not arbitrary revision history.
Something is missing or looks wrong
What you see: The current view does not contain the record, field, source, or output you expected.
What may be happening: Server scope, viewer permission, filters, source availability, feature gates, or stale state can change what the product may show.
What to do
- Confirm notes.create or notes.manage as appropriate.
- Verify the member ID before submitting again.
- Refresh the note list before assuming a save failed.
- Use a clarifying note and authorized deletion rather than duplicating sensitive text.
Use the correct note record
| Record | Audience and purpose |
|---|---|
| Member note | Attributable context about one server member for permitted moderation staff. |
| Case comment | Case participants and reviewers within the Case visibility boundary. |
| Appeal internal note | Appeal reviewers; never delivered to the appellant. |
| Assignment comment | Assignment participants who can view the assignment source. |
| Moderator administrative note or evaluation | Authorized leads under separate staff-management permissions. |