How to track staff applications in a Discord server

Most servers collect staff applications with a Google Form or a ticket bot. Collecting them is the easy part. The mess shows up afterwards: which applications has someone read, who's interviewing whom, and did anyone ever reply to the person who applied in March?

This guide sets up an application tracker your staff team uses from Discord. It doesn't replace the form members fill in (more on that below). It's the review pipeline that comes after.

What the tracker looks like

One row per application, with:

• applicant (Discord member, required)
• role applied for (text, required)
• status (Submitted, Under Review, Interview, Accepted, Rejected; required)
• submitted date
• reviewer (Discord member)
• notes

That's the Application Tracker template in CordBase, which we make. This guide builds it by hand instead, with one extra column, for a reason explained in step 1.

Step 1: Create the table

1. Sign in at cordbase.gg with Discord, pick your server, and add the bot when prompted.
2. Create a table named "Apps" with an applicant name text column first, then the six columns above. The command will be /apps.

Why the extra column: when staff pick a row to update, CordBase searches and lists rows by the table's first text column. In the template that's "role applied for", so ten Moderator applications would show up as ten identical "Moderator" entries. A name column first makes each row easy to find.

Step 2: Restrict it to staff

Applications are private-ish, so set permissions before anyone uses it:

• Your staff role gets write (add and update rows).
• Your admin or head-mod role gets admin (also delete).
• Don't give any other role a level. Once a table has any role set, members without one of those roles can't use it at all, which is what you want here.

Also make sure the channel where staff run these commands is staff-only. Results from query, view, add and update are posted in the channel where the command runs, so anyone who can see that channel can see them. Only errors and delete confirmations are private.

Step 3: Log applications as they come in

When an application arrives, a staff member logs it:

/apps add applicant_name:Rin applicant:@Rin role_applied:Moderator status:Submitted submitted_date:2026-10-08

Step 4: Work the queue

• /apps query status:Submitted shows everything nobody has picked up.
• /apps query reviewer:@Sam shows Sam's queue.
• /apps update row:Rin status:Interview reviewer:@Sam notes:Interview Fri 8pm moves an application forward. Start typing the applicant's name in row and pick it from the list.

Because the queue lives in a table, nothing depends on someone remembering which form responses they've read.

Where the form fits

CordBase doesn't collect application answers itself; members don't fill in a form through it. Keep using whatever gathers the answers (a Google Form, a ticket bot, or an application bot that DMs questions) and use the tracker for status. The notes column is a good place to paste a link to the full response.

After the cycle

• Paid plans export the table to CSV or JSON, which is handy for an end-of-term review.
• Rejected and accepted rows can stay as a history, or an admin can delete them. Deleted rows are purged after 30 days.
• Free plans hold 100 rows per table, which covers a lot of application cycles for most servers. Pro raises it to 10,000.