Settings and logging
Configure server roles, channels, moderation destinations, logging behavior, and guarded feature settings with reversible changes.
- Audience
- team lead · server admin
- Availability
- free · private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
What server settings control
Settings exposes selected-server role and channel choices for core moderation, jail behavior, action logs, message logs, Ban Review, appeals, temporary bans, supervised access, trusted sources, and team configuration where enabled.
Record the live value before editing
Opening Settings and saving a section require the corresponding effective settings permission. Some tabs appear only for administrators who can manage that feature or team mapping.
Open Settings for the selected server, choose one tab, and compare the current values with live Discord roles and channels before saving.
- A documented reason for the specific configuration change.
- Existing destination names and Discord IDs recorded for rollback.
- A live role/channel list and permission to manage the affected setting.
Change and test one setting
Choose one settings area
Limit the change to core configuration, logging, supervised access, network/sources, access, or teams.
Check: Unrelated values remain untouched.
Validate live Discord objects
Select existing roles, text channels, categories, or forums and confirm their intended visibility.
Check: The form does not depend on a stale or similarly named object.
Save and read feedback
Submit the supported form once and wait for explicit success or error feedback.
Check: The administrator knows whether the selected-server write completed.
Exercise one representative event
Perform a safe test that should produce the configured log or routing result, then inspect the destination and permissions.
Check: Stored settings and actual server behavior agree.
Confirm the stored value and Discord result
The selected server saves a validated configuration and produces the expected moderation/log routing without widening staff-only visibility.
Settings areas and ownership
| Area | Controls | Typical owner | Representative test |
|---|---|---|---|
| Core roles and channels | Moderator role, jailed role, jail category, core destinations, and related server objects. | Server administrator. | Health object and hierarchy checks. |
| Moderation action logging | Main/fallback log and specialized warn, mute, ban, jail, release, and related destinations where exposed. | Team lead or server administrator with settings authority. | One safe action and one reversal route to the intended staff channel. |
| Message/member/voice logging | Supported metadata destinations and collection behavior. | Server administrator with privacy review. | A controlled metadata event; confirm ordinary message content is not assumed. |
| Cases and Ban Review | Case/review channels, forums, escalation channels, and reviewer roles. | Case-review lead or server administrator. | Create a fixture case/review and inspect visibility/routing. |
| Appeals | Public appeal enablement, review routing, and related destinations exposed by the current form. | Appeals lead or server administrator. | Use a safe fixture submission and verify public/private separation. |
| Temporary actions | Expiry notifications or destinations for supported temporary moderation. | Moderation lead. | Review a short fixture only where policy permits; otherwise inspect stored validation. |
| Soundcheck | Feature enablement, supported limits, channels, visibility, and retention settings exposed by the UI. | Voice-evidence administrator. | One short consent-noticed session. |
| Supervised access | Tier roles, public echo, private review, escalation, and supported commands. | Training lead or server administrator. | One allowed supervised command and one denied command. |
| Trusted sources/network | Explicit trust participation and configured external source channels/categories. | Server administrator with data-review responsibility. | Source resolution and preview provenance. |
| Moderation teams | Role mappings, order, enabled state, escalation, and permission keys. | Least-privilege permission manager. | Representative account access tests. |
Logging destinations and fallbacks
A specialized moderation destination can fall back to a main log when the server has not set a separate channel. That can make an action appear to work while a specific setting remains empty. Always compare the saved specialized value, fallback value, and actual message destination.
| Check | Question |
|---|---|
| Stored ID | Does the form show the intended current channel/category/forum ID, not only a name? |
| Bot visibility | Can the bot view, send, embed, attach, and read history as required? |
| Staff visibility | Can only the intended staff audience see the destination? |
| Fallback behavior | If the specialized field is empty or invalid, which main destination receives the event? |
| Event type | Did the representative warning, mute, ban, jail, appeal, or other event route to the expected destination? |
| Failure behavior | Does a log-delivery failure remain distinguishable from the moderation action itself? |
Change one setting with rollback
Write the objective
State the problem, affected workflow, expected destination/behavior, and why the change is authorized.
Check: The change has a reviewable purpose.
Capture current values
Record existing IDs and options plus a safe screenshot when permitted.
Check: Rollback values are available.
Validate the replacement
Resolve the live Discord object, inspect its overwrites and bot permissions, and confirm it belongs to this server.
Check: The replacement is usable before saving.
Save once
Change only the intended tab/fields and wait for explicit success or validation error.
Check: Unrelated settings remain stable.
Run one representative test
Trigger or preview the exact workflow and inspect both stored record and Discord result.
Check: The change works in practice.
Roll back if needed
Restore prior IDs/options through the same form and retest once.
Check: The last known working state returns with an audit-worthy explanation.
Common settings failures
| Symptom | Likely cause | Response |
|---|---|---|
| Selection disappeared | Discord object was deleted, became inaccessible, or the option list is stale. | Refresh, resolve the current object, and use Health to identify the stale ID. |
| Save succeeds but event goes elsewhere | Specialized destination is empty/invalid and the workflow used a fallback. | Review specialized and main log values plus the actual event route. |
| Save is denied | The viewer can read Settings but lacks the section's manage permission. | Request only the necessary manage capability. |
| Bot cannot post | Channel/category overwrites or bot role permissions changed after save. | Correct Discord permission and retest; do not repeatedly change the stored ID. |
| Wrong audience can see the channel | Inherited or explicit overwrites are broader than intended. | Stop using the destination, correct visibility, and review any sensitive exposure. |
| Concurrent changes overwrite each other | Two administrators saved overlapping settings from stale pages. | Refresh, compare current stored values, coordinate one owner, and reapply only the intended difference. |
Roll back a broken setting
A saved identifier can later become stale if a Discord role or channel is deleted or reordered. Fallback destinations can mask an unset specialized log, so review both the saved value and the event result.
The server does not match the change you made
What you see: A control is unavailable, validation fails, or the resulting server state differs from the intended configuration.
What may be happening: Selected-server context, Discord permission, ModFlow team permission, feature access, stale Discord objects, or concurrent changes may block the workflow.
What to do
- Confirm the selected server and settings permission.
- Refresh the live role/channel options.
- Restore the last known working value.
- Use System Health to locate stale objects or missing bot permissions.
Configure native Discord event logging
The current registry defines 18 categories and 140 events. Soundboard is available as a configurable destination but has no registered lifecycle events yet. Global, category, and event routes can inherit, target an authorized Discord channel, or be disabled. Several sensitive or high-volume events are off by default. The delivery outbox tracks retry and health state, while audit-log actor attribution remains best effort.
Message edits and deletes, poll votes, voice presence, invites, channel topics, AutoMod content, and audit actors can expose sensitive content when enabled. Use a staff-only destination and verify the bot can view, send, and embed there. Gateway intents, cache state, Discord audit logs, permissions, truncation, and API availability can leave gaps.