Forms
Ask your members anything — staff applications, feedback, bug reports, event signups — with multi-step forms that branch on earlier answers, answered inside Discord and collected in one reviewable queue.
Three ideas. Everything else on this page is a setting on one of them.
The questions, in order. Any question can be hidden unless an earlier answer says otherwise, so a member only ever sees what applies to them.
The message members click. One panel can offer several forms as buttons or a dropdown — so “Applications” is one message, not three.
What came back. Posted to a review channel with Accept / Reject buttons, kept in a searchable queue, and exportable as a spreadsheet.
What a member actually experiences
- They click a button on your panel (or run
/form open). - Azra asks the questions — typed answers in a popup, dropdowns and pickers one at a time.
- They get a confirmation, and (unless you turn it off) a DM with a copy of what they sent.
- Your staff see it in the review channel and mark it Accepted, Rejected or Archived.
Five minutes, in this order.
- Pick a response channel. Forms → Settings. This is where responses land for review; make it staff-only. Individual forms can override it.
- Build a form. Forms → Forms & Panels → + New form. Add questions from the library or write your own.
- Say what happens to it. The What happens to it panel beside the designer — collect responses, open a ticket, or both.
- Post a panel. On the same screen, + New panel on the left — tick the forms it should offer, pick a channel, press Post. Until a form is on a posted panel its card says Not on a live panel, which is the one thing easy to forget.
Fifteen, grouped by how Discord can actually collect them.
| Group | Types | How it is asked |
|---|---|---|
| Typed answers | Short text, Paragraph, Number, Email, URL, Date, Pattern-matched text | In a popup box, up to five questions at a time. |
| Pickers | Dropdown (one), Dropdown (many), Yes / No, User, Role, Channel | One per step, as its own message only that member can see. |
| Uploads | File, Image | Requested in a channel afterwards — Discord popups cannot take files. |
| Notes | Note / Info | Text the member reads and continues past. Asks nothing, stores nothing. |
Every type validates what it is given before the response is accepted: an email has to look like an email, a date has to be a date that exists (31 February is refused), a number obeys its minimum and maximum, and a pattern-matched field reports your hint rather than a regular expression.
Discord's popup takes at most five text boxes, holds no dropdowns, accepts no files, and cannot be followed directly by another popup. So a form is not one dialog — Azra plans it into a sequence: typed questions pack five to a popup, each picker gets its own step, uploads wait until the end.
The designer shows you that plan as you build, and it is computed by the same planner the bot runs — not an approximation. What the sidebar says a member will see is what a member sees.
The reason a form beats a text box.
Any question can carry a condition: only ask this if an earlier answer is / is not / is any of / contains / is greater than some value — eleven operators in all, including was answered and was left blank.
So “Which platform?” → PC can ask for a Steam ID, and everyone else never sees that question. The form is re-planned after every answer, which is why a branch can appear mid-way through.
| Rule | What happens |
|---|---|
| A condition pointing at a later question | Dropped, and the question is asked unconditionally. It could never have been true, and asked-but-unfiltered beats never-asked. |
| A condition pointing at a question that was itself hidden | False — a hidden parent never drags a hidden child into view. |
| Two questions with the same answer key | The second is renamed, so one answer can never overwrite another. |
| A required question on a branch nobody took | Not required. Only visible questions are ever demanded. |
| Mode | Result | Use it for |
|---|---|---|
| Collect responses | Stored and posted to the review channel. No ticket. | Applications, feedback, surveys, reports. |
| Open a ticket | Opens a ticket channel in the department that referenced the form. | Support intake. |
| Both | Opens the ticket and files a response you can report on. | Support you also want statistics for. |
| Setting | Effect |
|---|---|
| Required roles | Only members holding one of them may submit. Empty means anyone. |
| Max per member | How many times one person may submit. 0 means unlimited. |
| Cooldown | How long after submitting before they may again. The refusal tells them exactly when it lifts. |
| Opens / closes | A submission window. Outside it the form says it is not open yet, or that it has closed. |
| Anonymous | Staff never see who submitted — not in the review post, not in the queue, not in the export. What makes an honest feedback box possible. |
Rejected and archived responses still count toward the limit. The cap is on submitting, not on being accepted — otherwise a rejected applicant could re-apply forever.
Every response lands in your review channel as an embed with the answers laid out, plus four buttons: Accept, Reject, Reviewing and Archive. Pressing one records who decided and when, and the buttons stay visible — the decision remains part of the record rather than disappearing with the controls.
The same states are on Forms → Responses, where you can filter by form, state or submitter, search inside the answers themselves, and export any form's responses to CSV. The spreadsheet's columns are that form's questions, in the order it asks them.
Accept / Reject Form Responses is granted separately from the rest of the module, because deciding a staff application is a different level of trust from building the form that collects them.
| Command | What it does |
|---|---|
/form open <form> | Fill in a form right now. |
/form list · !form list | Every form the server accepts. |
/form post <form> · !form post <name> | Post one form as a button in this channel. Needs Manage Server. |
/form responses <form> | The most recent responses, with their review state. |
/form review <number> <state> | Set one response's review state, with an optional note. |
!form open deliberately does not exist: starting a form means showing a popup, and Discord only allows one in reply to a button or a slash command — never to a text message. !form post is that, said honestly.
What happened to my ticket forms?
They are all here, on Forms → Forms & Panels, set to “Opens a ticket”. Every department still points at the same form it did before. Nothing needs re-linking.
Can one form feed both a ticket and a response queue?
Yes — set it to Both.
Why did my file-upload question not get asked?
Uploads need a channel to be posted into. A form that opens a ticket asks for them inside the new ticket; a form that only collects responses names them in the confirmation instead, because there is nowhere private to ask.
Can members edit a response after sending it?
No. Give them a second submission instead — raise Max per member, or clear it entirely.
Nothing was posted to my review channel.
Check the form's own response channel (it overrides the server default), that the channel still exists, and that Azra can send messages in it. Responses are always stored either way — the review post is a delivery, not the record.
Do forms need a plan?
Yes, like every module other than basic giveaways and welcome messages. Responses already collected stay readable if a plan lapses.