Applications

Receive staff applications through structured forms.

How it works

You post an application panel listing the open positions. A member picks one, its questions are put to them, and their answers land in the review channel in front of the staff. Accepting grants them the position roles automatically and notifies them. That ends the chaos of applications arriving by DM.

Panels

Positions

Questions

Checking the answers

A question can demand a shape: a number (with a smallest and largest value, so an age question refuses prose), an email, a link, or a pattern you write yourself along with the sentence shown when it does not match. An answer that fails is not filed; the applicant is told what is wrong and handed a button that reopens the form with everything they typed still in it, so nobody starts over.

The direct-message requirement

Before the form opens, the bot checks it can reach the applicant by direct message, since every reply about their application arrives there. If their DMs are closed they are asked to open them before writing anything, rather than filling in the whole form for an answer they would never receive.

Opening and limits

Application requirements

Applying again

The base cooldown applies between any two applications, and two more override it by outcome: one after a rejection and one after an acceptance, in hours, both counted from the previous application. Leave them at zero and both fall back to the base one. Alongside them sits a total attempt count, so you can stop someone trying more than twice however long they wait.

Roles on a decision

Position messages

Claiming

Every filed application carries a claim button. When a reviewer presses it their name is recorded and the button goes dead, so two people never work the same application, and the applicant gets a note that theirs is being looked at. A claim is a signal, not a lock: accept and reject stay open to the whole reviewer role, so nothing stalls if whoever claimed it disappears.

The applicant copy

The accept or reject message carries a file holding their whole application: the position, when they applied, who claimed and who decided it, the questions with their answers, and the status and reason. It opens in a browser with no connection, and it can be switched off per position.

The applications queue

Tips

Staff applications over DMs mean lost requests, repeated questions, and no record of who was accepted or why. This system unifies the process: a panel listing the open positions, where a member picks one, is put through its questions, and has their answers land in the review channel in front of the people responsible.

Every position is fully independent: its name, description, and color, its own questions, the reviewer roles who accept and reject, the accept roles granted automatically to whoever is accepted, the accept message delivered to them, and its own log channel. So whoever reviews moderator applications is not the one reviewing designer applications.

Application requirements filter submissions before they arrive: required and blacklisted roles, a minimum account age, a minimum server membership, and a cooldown between one application and the next. Membership age is the most useful of them, since most weak applications come from accounts that joined yesterday.

And the general settings fix the look once: the default channel, the embed color, the footer text and icon, the thumbnail, and whether the timestamp shows.