Responses and ban appeals
Once someone submits, FlaviBot files the response on your dashboard and, if you asked it to, posts it into a staff channel with review buttons on it. This page covers both review surfaces, what a decision actually does, and the one form type with rules of its own: the ban appeal.
Where does a response land?
If the form has a submit channel, FlaviBot posts it there: the form's title, who answered, their answers, and a row of buttons — Accept, Deny, Dismiss and View on site. A ping role, if you set one, is mentioned on that post. An edited answer arrives as a fresh post titled Edited response; the earlier post stays where it is, while the dashboard keeps a single row for that person rather than two.
Long answers are shortened on the post, since a Discord message has a size limit and an essay belongs on the dashboard. View on site opens that exact response with everything in it.
Everything is also on the dashboard, under Requests > Forms then View responses, whether or not you configured a channel. That page has two tabs:
- Responses — the list, filtered by All, Pending, Accepted or Denied, 25 at a time. Opening one shows the full answers and the decision buttons, with room for a note.
- Stats — the same responses as aggregates, described below.
Who is allowed to review?
Anyone with Manage Server, plus whoever your dashboard access rules already let in. That is true of both the buttons in Discord and the dashboard page.
On Premium you can also name reviewer roles on the form. Someone holding one can accept, deny or dismiss a response from the buttons on the staff post without being given Manage Server. That is a Discord-side grant only: the dashboard's forms pages still ask for Manage Server, so a reviewer role hands out the buttons, never the dashboard, and never the right to edit or delete the form itself.
What does accepting or denying do?
The decision is recorded against the response with your name, plus your note if you decided on the dashboard — the buttons in Discord take no note. Deciding from the buttons also edits the staff post in place, to show the outcome and who took it; deciding on the dashboard leaves that post exactly as it was, buttons and all. Then the actions you configured on the form run:
| Decision | What happens |
|---|---|
| Accept | adds and removes the roles listed for an accepted response, and sends its DM |
| Deny | adds and removes the roles listed for a denied response, and sends its DM |
| Dismiss | records the decision and nothing else |
Failing to add one role does not abandon the others, and a respondent with DMs closed to FlaviBot simply does not get the message; neither undoes the decision.
Deciding twice is possible from the dashboard: reopen the response and change it. The buttons in Discord do not re-decide — a response someone already handled answers that it has already been dealt with, so two moderators clicking at once cannot double up the roles. That is also the answer the still-visible buttons give on a post whose response was decided on the dashboard.
What do the statistics show?
The Stats tab is free on every plan. It reads every response and reports, per question:
- choice, checkbox and dropdown questions — how many times each option was picked, in the order you wrote them
- rating scales — how many people picked each point, and the average
- number questions — the smallest, largest and average answer
- date and date range questions — the earliest and latest date given
- text and email or URL questions — how many people answered, and nothing more, since there is no meaningful distribution to draw
Export CSV on the Responses tab is the Premium counterpart: one row per response, with its id, the respondent, the status, the submission date and one column per question.
What is a ban appeal form?
A form whose Form type, on the builder's Access step, is Ban appeal instead of Standard. It is meant for people your server has banned, so it skips the membership and role checks entirely — a banned member is not a member — and applies a set of checks of its own instead.
Build it like any other form, then bind it on the dashboard under
Moderation, in the Appeal form field. From that point the Appeal
button in the ban DM points at your form instead of at the plain appeal link,
for both /ban and /tempban.
Someone opening it sees a You were banned banner with the date and the reason, then your questions. The moderator who issued the ban is never shown. If the reason is something you would rather not repeat back, Hide the ban reason keeps the banner and drops the reason from it.
Who can file an appeal
The checks run in this order, and the first one that fails is what the appellant is told:
| Check | Blocks the appeal when |
|---|---|
| Active ban | they are not actually banned on that server |
| Non-appealable reasons | the ban reason contains one of the words or phrases you listed |
| Appeal blacklist | a reviewer denied and blacklisted them on this server |
| One pending appeal | they already have an appeal waiting for a decision (on by default) |
| Cooldown | their last attempt was less than n days ago, whatever its outcome (7 days by default) |
| Waiting period | the ban is more recent than n days (0 by default, so no wait) |
Deciding an appeal
The staff post carries Approve, Deny and Deny + Blacklist. The third one denies the appeal and bars that person from filing another appeal on this server. That blacklist is kept per server rather than per form, so it covers every ban-appeal form you run, not only the one they used. It is not permanent: Blacklisted appellants, at the bottom of a ban-appeal form's responses page on the dashboard, lists everyone currently barred and removes them again. That panel needs Manage Server, since the bar spans every form.
None of the three touches the ban itself. Approving an appeal records your
decision and runs the form's accept actions; lifting the ban is still a
moderator's job, with /unban. That is
deliberate: an appeal is a request to be looked at, not a self-service unban.
