Supervised access
Configure role-based supervised commands, private review boundaries, escalation, and visible public echoes for developing staff.
- Audience
- team lead · server admin
- Availability
- private beta access
- Maturity
- alpha · partial
Last reviewed
On this page
Separate public echoes from private review
Supervised tiers map a developing staff role to configured commands, a public echo destination, private review and escalation context, lead/flag recipients, and per-command review behavior.
Define the supervised tier boundary
Server administrators manage tiers. Supervised staff receive only the configured command access, while authorized reviewers and leads receive the private review or escalation context required by the tier.
Open Settings → Supervised, create or select a tier, and configure its Discord role, echo channel, escalation destination, and supported commands.
- A Discord role for the supervised staff cohort.
- A staff-visible echo channel and authorized private review/escalation destinations.
- Named lead reviewers and a documented escalation policy.
Configure and test the review path
Define the tier boundary
Name the tier, map its role, set enabled state and order, and choose supported command behavior.
Check: The configuration applies only to the supervised cohort.
Configure public echo and private review
Choose the echo channel and review/escalation destinations with correct staff visibility.
Check: The public-facing moderation echo remains distinct from private reviewer discussion.
Set leads and flags
Select supported lead, escalation, or flag recipients without widening the review thread audience.
Check: Sensitive follow-up reaches authorized staff.
Test and escalate
Run a safe supervised command, verify the echo and private review state, then exercise one configured escalation path.
Check: The workflow preserves both replyability and private review boundaries.
Verify echo, review, and escalation
A supervised staff member can use only configured commands while authorized reviewers receive the intended private context and escalation path.
Supervised tier model
| Component | Purpose | Verify |
|---|---|---|
| Tier role | Defines the developing staff cohort. | Only intended members have the role and the role is mapped to the correct tier. |
| Supported commands | Limits which moderation commands enter the supervised route. | One allowed command appears; one unconfigured command remains unavailable/normal according to policy. |
| Public echo | Posts the approved public-facing moderation echo where configured. | Copy is appropriate for the public/staff-visible destination and excludes private review detail. |
| Private review | Keeps coaching, evidence, and supervisor discussion in an authorized space. | The supervised member, reviewer, lead, and ordinary members have the intended visibility/reply ability. |
| Escalation destination | Routes flagged or high-risk requests to authorized leads. | Correct channel/role receives the handoff without broad pings. |
| Lead and flag recipients | Defines who owns review and exceptional follow-up. | Recipients are current staff and understand response expectations. |
Configure a supervised tier
Define training scope
Choose the cohort, supported commands, required supervision, and escalation conditions.
Check: The tier has a documented learning objective.
Create or select the tier
Set name, role, enabled state, and order for the intended server.
Check: One tier maps the intended staff role.
Set public and private destinations
Choose the echo, review, and escalation surfaces and inspect Discord overwrites.
Check: Audiences remain intentionally separate.
Assign leads and flags
Select current reviewers/roles and define when they are notified.
Check: Every supervised action has a responsible review path.
Configure supported commands
Enable only commands the cohort is trained to use and review their per-command behavior.
Check: The tier does not silently expand to all moderation actions.
Run fixture tests
Test success, denial, escalation, and reply behavior with representative accounts.
Check: The public echo, private thread, and escalation all match policy.
Review supervised work constructively
| Area | Question | Record |
|---|---|---|
| Target and server | Did the supervised moderator act on the intended member in the intended server? | Action response and linked record. |
| Authority | Was the command allowed for this tier and current role? | Tier configuration and interaction result. |
| Reason | Does the reason identify behavior, policy, and context? | Action record; coaching stays private. |
| Proportionality | Was the action the least severe effective response under policy? | Private reviewer discussion and any Case. |
| Verification | Did the moderator check the actual result and side effects? | Execution result and history. |
| Coaching | What specific behavior should be repeated or changed next time? | Private review response; not public echo. |
Recover a leaking or blocked review path
Private review is visible too broadly
What you see: An ordinary member or unrelated staff role can see the review channel/thread or sensitive details appear in the echo.
What may be happening: Discord overwrites, inherited category permissions, selected destinations, or copied content may be incorrect.
What to do
- Disable the tier or affected command immediately.
- Stop posting further private detail.
- Correct destination overwrites and review the exposure.
- Run a safe fixture before re-enabling.
Supervised command never reaches review
What you see: The moderator sees denial or an action completes without the expected echo/review/escalation.
What may be happening: Role mapping, tier enabled state, supported-command configuration, destination access, or handler state may be wrong.
What to do
- Confirm the user's tier role.
- Check enabled state and command configuration.
- Verify bot permissions in all destinations.
- Use one fixture and inspect the original interaction plus resulting record.
Repair a leaking or blocked review path
Channel and thread permissions can drift outside the dashboard. A public echo is not the private review record, and a private thread must not be treated as visible to every moderator.
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
- Disable the tier if visibility is uncertain.
- Verify the mapped role and all destination channel permissions.
- Check lead/flag recipients and supported command settings.
- Repeat a safe fixture interaction before re-enabling normal use.