Docs / Recruitment

The pipeline board

How applications appear on the board, what a card tells you, how a move is attempted, and which parts of the current screen are real data versus placeholder.

5 min read·Last updated September 3, 2026

The board is one column per active stage, in sortOrder, with one card per in-progress application. It is a view onto the gate rather than a free-form kanban: where a card can go is determined by the stage configuration and the requirements attached to it, not by where you can drop it.

Getting onto the board#

An applicant on their own has no stage and no card. Creating an application — one applicant against one JobOrderPosition — is what puts them on the board, at the initial LEAD stage.

# Endorse an applicant to a position.
curl -X POST "$API_URL/v1/applications" \
  -H "Content-Type: application/json" \
  -H "X-CSRF-Token: $CSRF" \
  --cookie "hrteq_session=$SESSION" \
  -d '{
    "applicantId": "...",
    "jobOrderPositionId": "..."
  }'

Creating an application requires create application permission — a Recruitment Officer or an administrator — and fires the APPLICATION_CREATED automation trigger, which by default emails the applicant an acknowledgement.

What a card shows#

Each card carries the applicant’s name and number, the position, the principal, the jobsite country, when the application entered its current stage, and a progress figure.

That progress figure is the gate, evaluated live: it is how many of the next stage’s requirements are already satisfied out of the total. A card reading 3 / 4 is one requirement away from moving. This is the single most useful number on the board, because it turns “what is blocking this?” into a glance.

Time in stage#

stageEnteredAt is stamped on every move. It is what makes a stalled application visible, and it is what the stale-application automation reads: any application that has not moved in 21 days generates a follow-up task for the Recruitment Officer. See Automation rules.

Opening an application#

Opening a card fetches the application detail, which returns three things beyond the record itself:

The next-stage gate

Every requirement on the immediate next stage with satisfied and, when it is not, a detail string written for the officer — “Uploaded but not yet verified by the Document Officer”, “Expired on 2026-04-30”, “Outstanding worker balance of 4500.00”.

Available transitions

The stages you may move to right now, each annotated with whether your role permits it and whether the gate allows it. Unavailable targets are shown with the reason rather than hidden.

The checklist

The application’s checklist items, which you toggle from here. Completing the last requirement can advance the application on its own.

Moving an application#

From any stage you may move to the immediate next active stage, or to any terminal stage. You cannot jump three stages forward — the transition list simply does not offer it. That is deliberate: skipping stages is how compliance records end up with holes in them.

A move is checked in a fixed order: module write permission, then the target stage’s owning role, then the entry-requirement gate, then — only for an Owner or System Administrator — a written override reason. A blocked move returns 409 with code GATE_BLOCKED and the gate attached, so the client can list exactly what is unmet. Stage gates covers the rules in full.

Every successful move writes an ApplicationStageHistory row with the from and to stages, who did it, whether it was an override, and any note. Certain stages also stamp their own timestamp — entering Employer Interview sets endorsedAt, EO Status sets offerAt, Contract Status sets offerAcceptedAt, Deployed sets deployedAt.

Automatic advancement#

Most moves happen without anyone pressing a button. When an authorised action changes a gate fact — a document is verified, a checklist item is ticked — the server re-evaluates the immediate next stage. If every requirement on it is now satisfied, the application advances by itself with the note “Automatically advanced after all required stage items were completed.”

Automatic progression is deliberately narrow: it only ever moves one stage, only into the immediate next active stage, never into a terminal stage, and never through an unsatisfied requirement. A stage with no configured requirements is never auto-entered — otherwise an unconfigured stage would be a hole the process falls through.

Closing an application#

Terminal stages are reachable from anywhere and are never gated, because you must always be able to close a failed case. Entering one sets the application status to CLOSED_FAILED — or CLOSED_SUCCESS for Contract Completed — and records a TerminalReason.

Closing one application does nothing to the applicant’s other applications. A failed medical for a Saudi position does not touch their Japan pipeline.

What on this screen is not real yet#

The genuine activity feed is on the dashboard, which reads the audit log. See Audit trail.