Skip to main content

Custom Commands Usage Guidelines

danger

These policy are subject to review and changes as the product they govern isn't available to non-approved partners yet.

About this document

Custom command flows let you build powerful automations that run with your bot's full permissions. These guidelines explain what responsible use looks like in practice and what the platform enforces.

They are a practical companion to the SCNX Terms of Service (in particular its provisions on custom bots, automated measures, and AI functions) and, if you share or publish flows, the Shared Marketplace Content Terms of Service. These guidelines do not replace those documents.

Last Updated: July 14, 2026

1. The ground rules​

  • Your flows are your responsibility. You configure them, you own what they do. Automated actions (deleting messages, timing users out, assigning roles, sending messages, ...) execute exclusively based on rules you set, and the Terms of Service place responsibility for that configuration with you.
  • Flows run with your bot's full permissions. There is no separate permission model per flow: anything your bot's Discord role allows, a flow can do. Grant your bot the permissions it needs (not more!) and treat every flow you activate with the same care as giving a moderator those permissions.
  • Custom command access is bot-level power. Anyone who can edit custom commands, including trusted admins, can build flows that act with your bot's full permissions, which may be far more than their own: a flow can assign roles, ban members, or delete channels on behalf of whoever triggers it. Only grant custom-command access to people you would trust with your bot's permissions directly, and review your trusted-admin permissions when you enable the feature.
  • Discord's rules apply to your automations. Everything your flows do on Discord must comply with Discord's Terms of Service and Community Guidelines, exactly as if you did it manually.

2. Prohibited uses​

Flows must not be built or operated to:

  • Spam or mass-message: automated mass-messaging, unsolicited bulk direct messages to members, or any automation designed to flood channels or inboxes.
  • Raid or grief: automations that damage servers or harass communities, whether your own or others'.
  • Deceive: flows that impersonate Discord system messages, other bots, or staff; fake "verification" interactions; or any interaction designed to mislead members about what they are clicking or submitting.
  • Harvest personal data: collecting real names, addresses, phone numbers, emails, identity documents, or other sensitive real-world data from members through modals, forms, or message prompts. This is prohibited even with a stated purpose; Discord communities are not a place to collect identity data.
  • Harass individuals: automations that target, track, or repeatedly action specific members beyond legitimate, proportionate moderation.
  • Evade platform rules: circumventing Discord rate limits or enforcement, bypassing SCNX plan restrictions, or working around the platform safety limits described in Section 5.
  • Exfiltrate data: see Section 4 for what external requests may and may not do.

Violations can lead to flows being disabled, custom-command access being revoked, or account-level enforcement under the Terms of Service.

3. Member data and your legal responsibilities​

Flows can store data about your members (levels, warnings, signups, preferences). Under the GDPR you are the data controller for member data your server processes; SCNX processes it on your behalf. In practice:

  • Know what you store. Your storage schema and the storage browser in the dashboard show every field your flows persist. You are expected to be able to answer, at any time, what personal data your custom commands hold and why, that expectation comes directly from your Data Processing Agreement with us.
  • Store the minimum. Design storage fields around what the feature needs. A leveling system needs an XP number per user; it does not need message content.
  • No sensitive data. Do not design flows that store special categories of personal data (health, religion, political opinions, sexual orientation) or real-world identity data. The platform is not designed or contracted for it.
  • Be transparent about automated moderation. If your flows automatically warn, mute, time out, kick, or ban members, EU law (GDPR Art. 22) and the Terms of Service require transparency about automated decision-making. Practically: state in your server rules that moderation is partly automated and what triggers it, and give members a human path to contest a decision (a modmail, a ticket, an appeal channel). An automated ban with no disclosed rule and no human review might be legal risk.
  • Honor deletion requests. When a member exercises their right to erasure, delete their entries from your flow storage too. The storage browser lets you find and delete per-user entries; scheduled cleanup flows can automate retention limits.

4. External requests​

Flows can call external HTTP APIs. This is powerful and easy to misuse:

  • Sending data out is restricted. Data your bot obtained from Discord (message content, user details, member lists, server information, ...) must not be transmitted to external services except where you, as controller, have a lawful basis, it is genuinely necessary for a feature your members understand and in a manner that is complaint with Discord Developer Terms of Service. For any flow you share or publish, the rule is absolute: marketplace-distributed content may not transmit Discord-obtained data to external servers in any scenario (Marketplace Terms §3.4).
  • Only call APIs you trust. External endpoints receive your requests and can see whatever you put in them. Use documented, reputable APIs; never call endpoints designed to scrape Discord or execute untrusted logic.
  • Never put secrets in flow steps. Flows are exportable, shareable, and inspectable by anyone with dashboard access to your server. An API key pasted into a flow step should be considered exposed, and if the flow is ever shared or published, it is. Rotate any credential that has been in a shared flow.
  • Expect rate limits. External calls consume your execution budget (Section 5) and slow your flows. Cache with storage fields where possible instead of calling on every trigger.

5. Platform safety limits​

CCV3 has a safety layer that runs on every execution. It exists to keep one bad flow, malicious or just buggy, from taking down your server or your bot:

  • Execution limits. Every run has a hard ceiling on total steps, covering loops and nested flow calls. A run that hits the ceiling is stopped with a limit-exceeded error visible in the execution log. This is almost always a sign of an unintended loop, you should check the execution trace.
  • Budgets. Flows consume from per-server execution budgets, with destructive actions (deletions, bans) budgeted separately and more tightly. The budget gauges on the Custom Commands overview show where you stand; the dashboard warns you before automation is paused.
  • Kill switch and emergency stop. SCNX can halt flows that trip abuse detection. You also have your own emergency stop on the overview page; it immediately stops every flow and module on your server and can be reverted at any time. If your automations ever misbehave, use it first and debug second.
  • Privileged access needs opt-in. Triggers that need privileged Discord intents (member events, message content) require enabling those intents for your bot and a bot restart; the editor tells you when this applies. Only enable the intents your flows actually use.

These limits are part of the service, not a challenge: deliberately engineering around them (splitting work across flows to evade budgets, hammering retries against limits) is a violation of the Terms of Service.

6. AI-generated flows​

If you generate or modify flows with AI assistance (including SCNX's AI tools), the result is your configuration; the same responsibility rules apply as if you had built it by hand:

  • AI-generated flows on SCNX are created as drafts and never run until you activate them. External AI Integrations may enable flows on your behalf if you let them.
  • Review before you activate. Read what the flow does; especially any moderation actions, external requests, and storage writes. Use a test run first; it simulates the flow without sending, changing, or deleting anything.
  • AI output can be wrong. The Terms of Service are explicit that AI results carry no accuracy warranty and must be verified by you before use.

7. Building responsibly​

We suggest to follow the following steps:

  • Test-run before activating, and after every significant edit. The execution log shows you every step, input, and output of real runs when something goes wrong later.
  • Use cooldowns on message- and reaction-triggered flows to prevent feedback loops and accidental spam.
  • Keep drafts as drafts. Unfinished flows should stay off; the editor reminds you when a saved flow isn't live yet.
  • Prefer configuration over hardcoding. Modules with configuration pages survive server changes and are shareable; hardcoded IDs break silently.
  • Watch your executions page after activating something new, the first hour of real traffic finds what test runs don't.

8. Reporting​

If you encounter flows or shared content being used abusively, on your server or anywhere on SCNX, report it to [email protected] or through the support form. For content imported from the marketplace, include the listing URL or import key.