Applicant Tracking System and Candidate Tracking

The screen has three panes: search box, filter bar and application list on the left; the selected candidate detail in the middle; that candidate document on the right. Pane widths are dragged to taste. On mobile, selecting a candidate hides the list and the filters, and the back bar clears the selection.

Selecting a candidate does not change the route, the selection is written to a parameter in the address bar. In practice: set your filters, click a candidate and the list does not reload, refresh the page and the same candidate is still open and you can send that address to a colleague.

Job applications and internship applications live in separate tabs but share the same shell. The internship side carries three more filters: university, insurance and internship type.

• The list loads page by page, 20 records per page
• Row height is fixed at 80 pixels; the skeleton uses the same height, so the list never jumps when data lands
• Search runs over first name, last name and email and folds Turkish characters: typing "yilmaz" finds "Yılmaz"
• Filters on the job side: status, posting, province, district, field of study, experience
• Filter options are produced from the posting own data; when the option list is empty, that filter is not shown at all
• The "Imported from Google Drive" badge in the list appears only on imports made on the Enterprise plan, it is not a default state

An application moves along a single five step line: Pending, Reviewing, Interview, Accepted, Rejected. The pool funnel uses the same order. Hired and everything after it belongs to the employee side, so it never enters the funnel.

The label, color and icon of a status come from one central resolver. The badge in the list, the badge on the detail and the badge in the email confirmation dialog read the same dictionary; no component keeps its own color table. Next to the badge, the row tint follows the status as well.

One caution: a step is not worded identically on every surface. The step badged Interviewed in the list reads Interview on the detail status button and in the audit log. When you walk someone through a screen, use the label that screen carries.

Interview exists as an application status on every plan. Interview scheduling with Google Meet is a separate capability and is open on the Professional and Enterprise plans; the two should not be confused.

GoTeam never rejects candidates automatically. AI makes suggestions, HR decides; no application changes status on its own. The note on the bulk action bar says the same: "AI only makes suggestions; status changes are applied with human approval."

Every status change passes through a single service and requires a user identity. The change is written field by field to the audit log: which field changed, what its old value was, what the new one is, who did it and when. A field event is recorded inside the same operation.

If two people update the same application at once, the second one does not silently overwrite the first. The update has to match the last change stamp on the record; if it does not, the request comes back and the user is asked to refresh the page.

Rolling an application back from Accepted or Hired does not work directly while it has open document or information requests. The system counts the open requests and asks for confirmation; forcing past it requires a written justification, and that justification lands in the audit log as its own field. The document request chain is open on the Professional and Enterprise plans.

• Rights are split by action rather than by status: viewing, creating, changing status, writing notes, editing, deleting and exporting are separate permissions
• A user with the note permission cannot change a status; the request is rejected and says which permission is missing
• Bulk status change lives inside the AI advisor rather than the applications screen and has three gates: the AI analysis setting has to be on in the panel, the user needs the AI advisor management permission, and the capability has to be included in the plan
• Every read and write is filtered by company id; that id is read from the authorization gate of the session, never from data the browser sent

Changing a status never emails the candidate automatically. The confirmation dialog offers two buttons: "Update Only" and "Send Email". If email notifications are off for the company, the dialog says so and comes down to a single button.

Not every step has a status email template for the candidate. Accepted, Rejected and Reviewing have one; Interview and Hired transitions have no candidate facing template, so the email is skipped.

A second email is never sent for the same transition. The holding key is built from the company, the application and the last change stamp before the transition; even if the same transition fires again, the candidate gets no second message.

While the detail pane is empty, the talent pool summary takes its place: four number cards, the funnel distribution, top candidates, a status chart per posting and the waiting list. The summary reads exactly the filter set of the list, so the totals on screen and the rows in the list come from the same scope.

The four numbers are: total applications, applications with an AI analysis, average score and waiting candidates. The label of the average says what is being averaged; when the scanned pool holds stored position fit records it reads "Avg. position fit", otherwise "Avg. CV score". A candidate without a score is not counted as zero and dumped at the bottom, they are left out of the calculation.

The summary makes no AI call at all, it only reads stored scores. The fit of older applications against their own postings can be computed in bulk afterwards; the request moves to the background and records that are already current are skipped. This job never runs while the AI analysis setting is off in the panel.

Whether the same candidate has applied before appears as a banner on the detail. Matching looks at contact details rather than identity: email and phone together make a strong match, email alone a medium one, and a phone on its own counts only when the name matches too. The reason a phone number alone is not enough is concrete: a switchboard number, a home phone or a placeholder number gets shared by people with no connection to each other.

• "Waiting" comes from a defined threshold: applications that have stayed Pending or Reviewing for more than 7 days
• The attention list shows at most 12 rows, oldest first; the posting breakdown covers at most 8 postings, and a pool scan at most 5,000 records
• Putting two candidates side by side works inside the list: in comparison mode a click selects, at most two candidates are held, and clicking a third replaces the second slot
• The comparison report triggers no new AI call, it is computed from stored analysis data alone; for a candidate without an analysis the report stays empty

KVKK masking is a role property. A user attached to a role marked masked receives data that is already masked on the server: the name drops to an initial, email and phone are shortened, CV and transcript links are emptied. The same masking runs on the list, the detail, the pool summary and the export endpoints; the blur on screen is a presentation layer on top of that, never the only defense.

A masked user cannot delete a candidate: the delete button on the row and its confirmation dialog are not drawn at all while masking is on. The document viewer does not open the file either, it says "This file is hidden under KVKK." The audit log does not disappear, its content is hidden; when a sensitive field changed, the row reads "Email: changed", so who changed it and when stays readable while the old and new values do not.

Deleting an application is not permanent. The record is soft deleted and can be restored from the trash; lists leave deleted records out anyway. Job and internship applications are among the restorable types of the trash.

On export, columns are picked one by one, the filter panel uses the same options as the list, and a preview table shows what will come out before you download. A single query pulls at most 10,000 records.