10/14/2026
A Discord ticket bot should be private before it is clever
Plan a support ticket flow in Bottly, check channel permissions with real member roles, and avoid the mistakes that turn a private conversation into a public one.
A support ticket often starts with something a member would not post in public: an order problem, a report about another member, or a question about their account.
That makes privacy the first requirement. The colour of the opening embed, the button emoji and the ticket number can wait.
Bottly's flow builder can connect a command or button to channel creation, permission changes and replies. Those blocks give you the pieces for a ticket system. They do not remove the need to decide who can see a ticket and test that decision in Discord.
For a basic community support system, the rules might be:
Keep the staff group narrow. If every helper, event organiser and former moderator shares the support role, then “private” means private from members, not private from all those people.
Also remember Discord's Administrator permission. Administrators can bypass channel permission restrictions. Do not tell a member that only one specific support agent can read a ticket if server administrators can also access it.
Create a ticket category in Discord and review its permissions before wiring up the flow. Deny ordinary members access, then give the intended support role and bot the permissions they need.
Do not assume a channel becomes private just because it is called a ticket. A newly created channel may inherit permissions from its category. If your flow creates it somewhere public and only denies access in a later step, you have a privacy gap.
Use a private parent category, inspect the creation settings, and check the resulting channel in Discord. If your chosen setup cannot create the channel with safe initial access, do not collect sensitive details in it until that is resolved.
Keep the public entry point somewhere else: a support channel containing a button, or a slash command members can run without seeing existing tickets.
A sensible first version has this shape:
In Bottly, the relevant building blocks include command or button triggers, Create Channel, Set Channel Permission, and a reply or message action. See Automations and the flow builder for how triggers, conditions and actions fit together.
Save the created channel's reference using the creation block's output setting, then use that result in later actions. Do not accidentally send the opening message to the public channel where the member clicked the button.
Set channel permissions deliberately. The requester needs access to view and reply; the support role needs the appropriate access too. Check whether your flow inherits or overrides the category settings rather than assuming the result.
For the final interaction reply, use ephemeral feedback where supported. A short “Your ticket is ready” response should not announce the member's issue to the whole server.
A support prompt should help someone explain the problem, not ask them to paste everything they know.
Change the final sentence to match how your team really works. Do not advertise a response time you have not agreed to maintain.
If an order reference is needed, ask for the reference rather than a screenshot of an entire payment page. The less sensitive information you collect, the less you have to protect later.
You need more than an administrator preview. Use these roles in a test server:
Open a ticket as the requester. Confirm that they can read the opening message and reply. Switch to the unrelated member and confirm that the ticket is not visible. Then check the support agent can enter and respond.
Repeat the test after changing the category permissions. A channel that is no longer synced with its category may behave differently from the next ticket your flow creates.
Also try a support agent who has more than one role. Discord permission combinations can expose mistakes that a simple test role misses.
A member may click twice because their connection is slow. Two clicks should not quietly create an unlimited pile of channels.
If you want one open ticket per member, design that check explicitly. It needs a record of the member's current ticket, not just a temporary value from one flow execution. Bottly's ordinary flow variables are not a substitute for persistent storage between separate events.
Keep a record when the ticket opens and clear or update it when the ticket closes. Handle the case where someone deleted the channel manually but the record still exists. Until that logic is implemented and tested, do not promise duplicate prevention.
A visible Close button is not an access-control rule. The flow handling it must check whether the person clicking it is allowed to close that ticket.
Decide whether closing means locking the conversation, moving it, or deleting it. Deletion is difficult to undo, so make it a deliberate choice. If you need a transcript or audit record, implement and test that before relying on deletion as your normal process.
Do not assume the ticket template automatically provides transcripts, retention rules or a recovery mechanism. Verify each feature you depend on.
Before adding the support button to your main server, confirm that:
A plain ticket system that passes these checks is ready for real questions. A beautiful one that fails them is not.
That makes privacy the first requirement. The colour of the opening embed, the button emoji and the ticket number can wait.
Bottly's flow builder can connect a command or button to channel creation, permission changes and replies. Those blocks give you the pieces for a ticket system. They do not remove the need to decide who can see a ticket and test that decision in Discord.
Write the access rules first
For a basic community support system, the rules might be:
The person opening the ticket can see and reply in it.
A named support role can see and reply in it.
Other ordinary members cannot see it.
The bot has enough access to manage the conversation.
Closing or deleting a ticket is restricted to the people you choose.
Keep the staff group narrow. If every helper, event organiser and former moderator shares the support role, then “private” means private from members, not private from all those people.
Also remember Discord's Administrator permission. Administrators can bypass channel permission restrictions. Do not tell a member that only one specific support agent can read a ticket if server administrators can also access it.
Prepare a private category
Create a ticket category in Discord and review its permissions before wiring up the flow. Deny ordinary members access, then give the intended support role and bot the permissions they need.
Do not assume a channel becomes private just because it is called a ticket. A newly created channel may inherit permissions from its category. If your flow creates it somewhere public and only denies access in a later step, you have a privacy gap.
Use a private parent category, inspect the creation settings, and check the resulting channel in Discord. If your chosen setup cannot create the channel with safe initial access, do not collect sensitive details in it until that is resolved.
Keep the public entry point somewhere else: a support channel containing a button, or a slash command members can run without seeing existing tickets.
Build a small opening flow
A sensible first version has this shape:
Member requests support
→ Create a channel in the private support category
→ Set the requester's access
→ Set the support role's access
→ Send a short opening message inside the ticket
→ Reply privately to the requester with the channel link
In Bottly, the relevant building blocks include command or button triggers, Create Channel, Set Channel Permission, and a reply or message action. See Automations and the flow builder for how triggers, conditions and actions fit together.
Save the created channel's reference using the creation block's output setting, then use that result in later actions. Do not accidentally send the opening message to the public channel where the member clicked the button.
Set channel permissions deliberately. The requester needs access to view and reply; the support role needs the appropriate access too. Check whether your flow inherits or overrides the category settings rather than assuming the result.
For the final interaction reply, use ephemeral feedback where supported. A short “Your ticket is ready” response should not announce the member's issue to the whole server.
Keep the first message useful
A support prompt should help someone explain the problem, not ask them to paste everything they know.
Tell us what you were trying to do and what happened instead.
If there is an error, include its wording.
Do not send passwords, bot tokens, recovery codes or full payment details.
A member of the support team will reply here.
Change the final sentence to match how your team really works. Do not advertise a response time you have not agreed to maintain.
If an order reference is needed, ask for the reference rather than a screenshot of an entire payment page. The less sensitive information you collect, the less you have to protect later.
Test privacy with three different people
You need more than an administrator preview. Use these roles in a test server:
Requester: an ordinary member who opens the ticket.
Unrelated member: another ordinary member who should not see it.
Support agent: someone with the intended support role but no Administrator permission.
Open a ticket as the requester. Confirm that they can read the opening message and reply. Switch to the unrelated member and confirm that the ticket is not visible. Then check the support agent can enter and respond.
Repeat the test after changing the category permissions. A channel that is no longer synced with its category may behave differently from the next ticket your flow creates.
Also try a support agent who has more than one role. Discord permission combinations can expose mistakes that a simple test role misses.
Decide what a second click should do
A member may click twice because their connection is slow. Two clicks should not quietly create an unlimited pile of channels.
If you want one open ticket per member, design that check explicitly. It needs a record of the member's current ticket, not just a temporary value from one flow execution. Bottly's ordinary flow variables are not a substitute for persistent storage between separate events.
Keep a record when the ticket opens and clear or update it when the ticket closes. Handle the case where someone deleted the channel manually but the record still exists. Until that logic is implemented and tested, do not promise duplicate prevention.
Make closing a separate, checked action
A visible Close button is not an access-control rule. The flow handling it must check whether the person clicking it is allowed to close that ticket.
Decide whether closing means locking the conversation, moving it, or deleting it. Deletion is difficult to undo, so make it a deliberate choice. If you need a transcript or audit record, implement and test that before relying on deletion as your normal process.
Do not assume the ticket template automatically provides transcripts, retention rules or a recovery mechanism. Verify each feature you depend on.
A final pre-launch check
Before adding the support button to your main server, confirm that:
New channels start with restricted access.
The requester and support role can reply.
An unrelated member cannot see the ticket.
The bot reports permission failures instead of leaving a misleading success message.
Repeated clicks have a defined outcome.
Closing checks the person who requested it.
Your opening message does not ask for secrets or promise unavailable support.
A plain ticket system that passes these checks is ready for real questions. A beautiful one that fails them is not.