Custom AutoMod Actions

[Rodentman87]

With the built-in AutoMod, it allows servers to filter out or flag messages before they're sent. This works great, and it can also work with bots, by having bots listen to the Auto Moderation Action Execution event. This currently allows bots to detect when a rule has been triggered and take action accordingly, but (as far as I've seen) hasn't gotten much use.

The current situation

With the current 3 built-in actions (alert, delete, and timeout), a lot of simple moderation can happen automatically, but you can't achieve more complex things like tracking multiple triggers of the rule, following a tiered system of actions, etc.

Bots can currently listen to the trigger events for automod rules to provide this extended functionality, but the UX for assigning them isn't great. The ways currently possible are:

1. The bot just listens to triggers of any automod rule with some specific configuration and counts those towards whatever action. (Very opaque)
2. Using a slash command or other in-discord method of binding the automod rule to an action. (Better UX, but there's no easy way to tell which rules are currently bound without running another command to check the config)
3. A web dashboard for configuring the bot (Works pretty well, but it difficult to set up, and a little annoying for users)

The other problem is this requires running a bot connected to the gateway in order to listen to these events, so HTTP-only bots can't take advantage of the features AutoMod provides.

Proposed solution

Allow bots to add custom AutoMod actions. These would be registered with Discord ahead of time similar to role connection metadata or slash commands, where the bot can provide a set number of available action types as well as what parameters they take.

For instance, let's say my bot provides a system where if a user triggers an automod rule X times within Y minutes, they will be timed out for Z minutes. I could register a custom action named "Throttled Timeout" (or similar, should also support i18n like slash commands), and the custom action would have 3 options, all numbers, named "Number of Triggers", "Time Limit", and "Timeout Length". Now that I've registered this custom action, any server that has my bot will see this in the list of available actions when configuring AutoMod rules. They can select the action and configure their parameters to add this action to the rule.

Now that it's configured, any time that AutoMod rule is triggered, my bot can listen for the Auto Moderation Action Execution and check if it matches my custom action. If it does, it can read the parameters and take action on the user.

This could also potentially trigger an interaction to be sent to bots that use them and allow HTTP-only bots to receive these events like that instead of over the gateway.

[anime-oni]

If you look in the DDev docs they allow you to create an auto mod rule

[Andre601]

And? The issue OP has is, that these automod rules are still just the basic stuff you have in your server settings, meaning you can't define a custom parameter to configure. Only a String to trigger on (optionally treated a regex) and actions to perform, which are the same as normal auto mod (block message, timeout user, report message to channel).

At least that's what I gathered. Not sure if Discord has changed some stuff, but I doubt it...

[mxcabre]

Bringing this up again in 2025 because it's more relevant than ever. AutoMod rules are a great tool for intercepting and moderating messages before they’re sent in the chat. However, there are significant gaps in how they function, or at least how they’re documented. For example, the execution order of rules is unclear, and it’s not fully explained how "allowlists" interact with wildcards (wildcards seem to consume characters, which can create vulnerabilities).

There’s also no built-in "anti-link" rule to allow specific domains while blocking others. This makes it difficult to block all links except for a few safe ones. Worse, wildcards can be exploited to bypass such rules, e.g., using https://allowed-domain.com<>https://evil-domain.com where "<>" acts as a separator. Configuring such rules effectively is tricky, especially since "custom block rules" don’t have an explicit execution order, and the merging of rules behind the scenes (likely for optimization purposes) adds another layer of complexity.

One potential improvement would be to allow custom AutoMod actions, enabling bots to handle more complex scenarios. Here’s an idea for how this could work: an "event" could be triggered to the bot’s WebSocket connection, allowing the bot to process the message and decide the appropriate action. While this approach could add latency and strain the API, a workaround might involve sending the full message payload to the bot with a signature valid for up to 3 seconds (similar to the default interaction response timeout).

The bot could then respond with the same payload and signature to either approve or block the message. This would eliminate the need for the Discord API to track user messages, as the signature would confirm the message originated from a specific user (e.g., user ID "X"). If approved, the bot could resend the message on behalf of the user.

Additionally, custom AutoMod rules could include a fallback action if the bot doesn’t respond in time (e.g., block the message, issue a timeout, etc.). This functionality could be extended to other events, such as bans, kicks, or timeouts, enabling bots to mitigate mass bans or enforce limits on such actions in real-time.

[Qjuh]

Trying to mitigate false positive of an automatic solution with another automatic solution only introduces other false positives/negatives. It doesn’t solve anything. You already receive an event when the automod hits and can decide to take action based on that (including alerting someone that it might be a false positive or undoing a timeout automod made or …).

[RealAlphabet]

Trying to mitigate false positive of an automatic solution with another automatic solution only introduces other false positives/negatives. It doesn't solve anything. You already receive an event when the automod hits and can decide to take action based on that (including alerting someone that it might be a false positive or undoing a timeout automod made or …).

I understand your point, but you're fundamentally mistaken because you're comparing apples to oranges. The metaphor here is that AutoMod functions as a finite state machine, it applies preconfigured rules deterministically without any capacity for adaptation or learning. In contrast, an AI system (or any machine learning-based system) can analyze data in a much broader context, detect nuances, and improve over time based on feedback.

The goal isn't to replace one automated system with another, but to complement the strengths of a finite state machine with those of an intelligent system capable of drastically reducing false positives through contextual analysis. Claiming that this approach "introduces other false positives/negatives" without acknowledging the significant advancements in AI technology ignores the incredible improvements in accuracy and adaptability these systems bring.

Additionally, your proposed solution of "taking action after the fact" after AutoMod has already punished or deleted a message, is inherently flawed. In such cases, the user still suffers an unjust penalty or block, even if only temporarily, which can harm the user experience and disrupt community dynamics. The purpose of this proposal is to prevent such situations by enabling intervention before any action is taken.

Finally, your argument seems to assume that all automated tools are fundamentally the same, which isn't the case. Combining tools like AutoMod with an advanced AI system would address the limitations of both when used independently, creating a more effective and balanced approach to moderation.

[erkinalp]

Discord's API is designed around predefined actions. Custom premoderation actions would break that pattern and might require a wholesale rearchitecture of API frontend and caches. GitHub, for example, has a GraphQL API, but it doesn't have a premoderation.

[mxcabre]

Discord's API is designed around predefined actions. Custom premoderation actions would break that pattern and might require a wholesale rearchitecture of API frontend and caches. GitHub, for example, has a GraphQL API, but it doesn't have a premoderation.

I don't really understand the link between the “caches”. It doesn't require a major change to the architecture either, but I understand that it's a break from the “predefined rules” model.

Solution 1
A webhook is triggered to the bot that created the predetermined customizable rule, the bot responds 201 or 403, and that's it.

Solution 2 (Better, does not require a lot of work)
If developers think this solution will cause a bottleneck or is too complex to implement, there's a much simpler solution. Add a new flag to messages indicating that the message is “minimized” (visible only to moderators), and moderators and bots can remove this flag. This way, the message is sent in the chat, but a bot can decide afterwards whether to let the message through or not. It's simple and elegant, just add a message flag.

Finally, it would be preferable to propose alternatives and contribute positively through your comments. What do you think of this second solution?

[erkinalp]

Add a new flag to messages indicating that the message is “minimized” (visible only to moderators)

By the way, this is also how Matrix implements premoderation and certain cases of postmoderation that Discord handles by timeouts (which can't stop events from being published with filter rules unlike Discord due to its decentralised nature): matrix-org/matrix-spec-proposals#3531