Case & Appeal Settings
This page documents the settings in the Case & Appeal Settings dashboard area.
Behavior & pre-execution
Section titled “Behavior & pre-execution”How Archivian behaves when cases are created.
Intercept native moderation
Section titled “Intercept native moderation”Captures when someone is banned, timed out, or kicked outside of Archivian and creates a case from it automatically. This catches native Discord actions as well as bans/kicks/timeouts issued by other bots.
Handy if people might accidentally use Discord directly, or during a transition to/from another bot. You can safely leave it on while also using Archivian for these actions — the bot ignores bans, kicks, and timeouts it issued itself.
Notify user on creation
Section titled “Notify user on creation”Attempts to notify the target user with a direct message. For bans and kicks, the DM is attempted before execution (disabling this speeds execution up slightly); for all other case types, the DM is sent after the action. What the DM contains depends on other settings, but at minimum the user learns the case type and which server it’s in.
The following sub-settings apply only when Notify on creation is enabled:
Notify in channel if DM fails
Section titled “Notify in channel if DM fails”If the user can’t be DMed (often a privacy setting, a deleted account, or having left the server), Archivian instead posts a publicly visible message — mentioning the target — in the channel where the command was run. For bans/kicks this is practically useless, so it’s recommended to leave it off for those types.
Show case reasons
Section titled “Show case reasons”Shows the user the reason the case was created when they’re notified. Usually you want this on. (It does not control whether they can see the reason on the website dashboard — that’s a separate setting.)
Show case creator
Section titled “Show case creator”Shows the user which staff member created the case. Whether users should know this varies by server philosophy, so it’s off by default. (Again, separate from website-dashboard visibility.)
Custom message
Section titled “Custom message”Attach an optional custom field (title and description) to the DM for each case type — for example, off-Discord contact details, links to a code of conduct, or clarifications about consequences. Shown only in the Discord message, never on the website.
After-action
Section titled “After-action”What Archivian does once a case is created.
Show recent cases
Section titled “Show recent cases”When confirming case creation, also show a summary of the user’s 3 most recent cases — bypassing permission checks. Useful for spotting a pattern of prior warnings or a previous ban. The summary shows each case’s type, SID, creator, and an excerpt of its first non-archived entry.
DM notification success
Section titled “DM notification success”Includes, in the staff confirmation message, whether the user was successfully DMed, whether a channel message was sent as a fallback, or whether nothing was sent. Useful against members claiming they never knew about a case.
Tips & tricks for staff
Section titled “Tips & tricks for staff”Sends a follow-up message with tips to the staff member after the confirmation — useful during a transition to Archivian or when staff forget post-case steps or available features.
- Explain entries — that a case can have multiple entries, and how to add them.
- Explain files — that files can be attached to a case, and how.
- Explain linked users — that users (e.g. victims) can be linked to a case for record keeping, with no side effects for the linked user.
- Explain linked cases — that related cases can be linked both ways (e.g. a warning that led to a timeout); linked cases share the same label.
- Explain case tips — about the tips themselves: how to turn them off and how to add your own.
- Custom tip — your own reminder per case type (title + description), e.g. “attach proof screenshots” or post-case protocol reminders.
Visibility settings
Section titled “Visibility settings”Control visibility for cases, resources, and fields.
Show creators
Section titled “Show creators”Whether targeted users can see who created a case when browsing their own cases on the dashboard. Depends on Show cases (no effect if they can’t see the case), affects existing and new cases, and is separate from the DM “show case creator” setting.
Show cases
Section titled “Show cases”Whether a new case is visible to the user by default on the dashboard. Users must be able to see a case to appeal it. Controllable per case; this only sets the default for new cases. When on, these sub-settings apply:
Show files
Section titled “Show files”Default visibility for case files (no effect if the case itself isn’t visible). When visible, the user can see the file’s original URL, type, size, upload date, the file itself, and — if Show creators is on — who uploaded it. Staff can override per file when uploading.
Show all entries
Section titled “Show all entries”Default visibility for new entries. Doesn’t affect existing entries.
Show first entry only
Section titled “Show first entry only”Always keeps the first entry visible while hiding the rest — useful when the first entry is the case reason and the others are internal notes. Redundant if Show all entries is enabled. (In Archivian, the “reason” you give when creating a case is actually the content of its first entry; cases can then have many entries.)
Alerts & mod-logs
Section titled “Alerts & mod-logs”Configure when and where Archivian sends case and appeal alerts. For each category you choose the events, the case types, and the destination channel.
Appeals
Section titled “Appeals”(No setting for Note cases — notes don’t have appeals.)
| Alert on… | …happens when |
|---|---|
| Created | a new appeal is created |
| Updated | a staff member is assigned or unassigned, or the appeal’s status changes |
| Verdict | the appeal is approved or rejected |
Alerts about the case itself (distinct from its entries, files, and links).
| Alert on… | …happens when |
|---|---|
| Created | a new case of that type is created |
| Updated | a case is archived or restored; a timeout or temp-ban duration is changed; the case’s visibility changes |
| Undone | a timeout or temp-ban is ended early (manually, by reducing its duration enough, or by expiring on its own); a permanent ban is lifted |
| Deleted | the case is permanently deleted |
Entries
Section titled “Entries”| Alert on… | …happens when |
|---|---|
| Created | an entry is added to a case (the first entry at case creation doesn’t count) |
| Updated | an entry is archived or restored, or its visibility or content changes |
| Deleted | an entry is permanently deleted |
| Alert on… | …happens when |
|---|---|
| Created | a file is uploaded to a case (the first file at case creation doesn’t count) |
| Updated | a file is archived or restored, or its visibility changes |
| Deleted | a file is permanently deleted |
Linked cases & users
Section titled “Linked cases & users”| Alert on… | …happens when |
|---|---|
| Created | a user is linked to a case, or two cases are linked together |
| Updated | the label of a linked user or of the linked cases changes |
| Deleted | a linked user is removed, or the link between two cases is removed |
Appeals
Section titled “Appeals”Settings for appeals, beyond alerting.
Allow appeals
Section titled “Allow appeals”Appeals are enabled per case; this sets the default for new cases. Appeals are useless if the user can’t see the case (Show cases must be on, or the case made visible), and aren’t supported for Note cases. When a visible case can be appealed, the user logs into Archivian.net, browses their cases, and creates an appeal; staff then approve or reject it, which triggers automatic actions such as unban or lifting a timeout.
Allow appeals on existing bans
Section titled “Allow appeals on existing bans”Lets users check for and appeal old bans from before Archivian was added (or where no ban case exists). When enabled, a ban case is generated on the fly if none exists when the user visits the ban-checking page, and that case is appealable regardless of your appeal settings. You can see a demo of the end-user flow:
- The user opens a direct link to check whether they’re banned in your server.
- If they’re banned and no case exists, a ban case is generated.
- The page loads an appeal form.
- The user can abort or submit. (If they abort, the generated case still remains.)
- On submit, they’re taken to inspecting the appeal they just created in their personal dashboard.