# Applications overview
An **application** is like a ticket, but with a review step in between. Instead of opening a channel when a member clicks the button, Ticket King collects their form answers and logs them in a review channel. Reviewers then click **Approve** or **Deny**.
## When to use applications instead of tickets
Pick applications when:
* You want to review and approve before talking.
* You would rather not create a channel per applicant.
* You want roles granted automatically on approve.
* You want a structured review process with reviewer notes.
Common use cases are staff applications, partner applications, role-grant requests, and admissions for invite-gated communities.
## When to stay with tickets
Stay with ticket panels when:
* You want to start a conversation right away.
* The decision is to help the member, not to approve or deny them.
* You do not have a structured intake.
## How applications differ from tickets
| | Ticket panel | Application panel |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| When the member clicks | A pop-up form appears if set, then a channel opens | A pop-up form opens |
| Where the conversation happens | In the channel | There is no channel by default. It is review-only |
| Where it lives | A Discord channel | An entry in the Applications dashboard and a log embed in a channel |
| Max questions | 5 (one form) | 5 (the same single-form limit) |
| Grant roles automatically | No | Yes, on approve |
| Eligibility gating | Per option, with Required Roles :crown: and Blocked Roles :crown: | Per option, plus account age and server-membership age |
| Outcome | The ticket closes | Approve or Deny |
| DM the member on outcome | A DM on close, optional | A DM on decision, optional, one toggle |
## The 5-question cap applies here too
Applications and tickets use the same form system. An application cannot ask more than 5 questions in a single submission. There is no way to split a form across more than one pop-up.
See [The five-question cap](/docs/forms/five-question-limit.md) for design patterns that work within 5.
## The full applicant experience
From the applicant's point of view:
1. **Click the apply button.**
2. **Eligibility check.** If they do not meet the account age, server-membership age, or required-role rules, they get a block message and cannot continue.
3. **Pop-up form opens.** Up to 5 questions.
4. **Submit.** They get a confirmation that the application was submitted.
5. **Wait.** A reviewer acts on it in the dashboard or with the Approve and Deny buttons in the log channel.
6. **Outcome.** If **DM Result to Applicant** is on, which is the default, Ticket King DMs them a result with the reviewer's reason. The reason is the public part of the decision pop-up.
## The reviewer experience
There are two places to review applications:
### In the log channel
Every submission posts a log embed with **Approve** (green) and **Deny** (red) buttons. A reviewer clicks one, and a small pop-up opens asking for an optional **reason** (max 1000 characters, can be DM'd to the applicant) and an optional **note** (max 1000 characters, internal only). On submit, the decision is recorded.
### In the dashboard
Open **Applications** in the sidebar. This is a queue of every submission, and you can filter and search it. Click any submission to see the answers, then act on it. The review queue is free.
→ [The Applications page](/docs/applications/the-applications-page.md)
## What you configure
Per application option:
* **Application Type.** A text label that shows as the form title.
* **Log Channel.** Where submissions are posted. This is required. Without it, submissions cannot be logged and reviewers will not see them.
* **Application Questions.** Up to 5.
* **Eligibility.** Minimum account age and minimum server-membership age.
* **Reapplication.** The Allow Reapplication toggle and a Cooldown Period in days.
* **Granted Roles.** The roles granted on approve.
* **Roles to Remove.** The roles taken away on approve, for example a "pending" holding role.
* **Reviewer Roles.** Who can approve or deny.
* **Required Roles** :crown: **and Blocked Roles** :crown:**.** The same per-option role gating as tickets.
* **DM Result to Applicant.** Whether to DM the applicant on the decision.
→ [Designing your application](/docs/applications/designing-your-application.md)
## Related
{% content-ref url="/pages/EF0pKGpqjZw3SVUPhXC3" %}
[Designing your application](/docs/applications/designing-your-application.md)
{% endcontent-ref %}
{% content-ref url="/pages/SY2AogFi0IChBYDf6uOE" %}
[The Applications page](/docs/applications/the-applications-page.md)
{% endcontent-ref %}
{% content-ref url="/pages/6JTPTdW19MhSD9tqoyAc" %}
[Create an Application Panel](/docs/panels/create-an-application-panel.md)
{% endcontent-ref %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://ticketking.xyz/docs/applications/overview.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.