Design AutoMod rules that moderators can trust
Choose clear triggers, safe actions and useful logs for automation that supports human moderation.
Prepared by the Sunatia product team from practical Discord community administration workflows.
Automate repetitive evidence, not difficult judgment
Automation is strongest when the pattern is objective: excessive mentions, repeated messages, known scam domains or posting faster than a reasonable limit. Context-heavy behavior such as sarcasm, conflict or misinformation still needs human review.
For each proposed rule, ask whether two reasonable moderators would agree on the trigger. If not, use the rule to flag content rather than punish automatically.
Match the action to confidence
Low-confidence detection should notify staff or hold a message for review. Medium-confidence detection can delete content and warn the member. High-confidence, high-impact attacks may justify a temporary timeout.
Permanent bans should rarely be the first automated action. Temporary measures stop immediate harm while preserving a path for review and correction.
Practical checklist
- Explain the triggered rule to the affected member.
- Include message, channel and trigger context in the staff log.
- Set an owner and review date for every automation rule.
Build exceptions narrowly
Broad exemptions create hidden attack paths. Exempt a trusted announcement bot from a link rule rather than exempting every account with a popular role. Review exceptions whenever permissions change.
Test rules in a private channel with realistic messages, including punctuation variations, languages used by the community and mobile formatting.
Treat false positives as incidents
When a legitimate message is blocked, record why the rule matched and how the action affected the member. Repeated false positives damage trust even when moderators reverse them quickly.
Use logs to compare prevented abuse with incorrect actions. Disable rules that cannot be made reliable; automation should reduce moderation risk, not merely increase the number of actions.
Stage a rule before it can punish members
Start with a written rule specification: the behavior to detect, the channels and roles in scope, examples that should match, examples that must not match and the least disruptive response. This prevents a keyword list from becoming the policy by accident. The human-readable specification should remain understandable even if the automation tool changes.
Run the detector against recent, representative messages or in an alert-only mode. Label each result as correct, harmless or ambiguous. A rule that catches obvious abuse but also flags common community vocabulary is not ready for automatic punishment. Narrow the pattern, add context such as repetition or account age, and test it again.
Use graduated responses. Blocking one message with a private explanation is safer than immediately banning an account when confidence is moderate. Repeated high-confidence behavior can escalate, but every escalation should have a maximum duration and a log entry that a moderator can review.
Practical checklist
- Write positive and negative examples before configuring the detector.
- Observe real matches before enabling automatic sanctions.
- Give each rule an owner, version and next review date.
Review the rule after incidents and platform changes
For every serious automated action, preserve the rule version and the signals available at that moment. Without a version, a later appeal may be judged against settings that did not exist when the message was sent. If Sunatia records the event, include the rule identifier in the moderation reason or linked case.
Review rules after a raid, a major false positive or a change in Discord features. Do not simply add the attacker’s wording to a blacklist. Ask which behavior allowed the incident to scale and whether rate, account or channel signals would detect the next variation with fewer innocent matches.
Retire rules that no longer protect a clear risk. Old exclusions and duplicated filters make the system harder to reason about and can conflict in ways moderators cannot explain. A smaller set of measured rules is usually safer than a large set nobody is willing to disable.