> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hr-easy.nlead.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Application pipeline

> The Kanban board, configurable stages, mailbox integration, and talent pools.

Applications live on a Kanban board, one column per **stage**. Stages are configured
per installation — the platform does not impose a hiring process on you.

## Configuring stages

Under **Settings → Pipeline**, a stage carries:

| Property             | What it does                                                                     |
| -------------------- | -------------------------------------------------------------------------------- |
| Name and description | Authored per locale (de / en / fr).                                              |
| Order and colour     | Where the column sits on the board, and how it reads.                            |
| Terminal + type      | Whether the stage ends the process, and what it *means* — `HIRED` or `REJECTED`. |
| Visible in portal    | Whether the applicant sees this stage in their own view.                         |
| Active               | Retire a stage without deleting the history that points at it.                   |

<Note>
  `stageType` is why the platform never has to guess a stage's meaning from its name. A stage called
  "Zusage" and one called "Offer accepted" are both `HIRED`, and the hire flow keys off that rather
  than off keyword matching.
</Note>

### Stage tasks

Each stage holds **tasks** — the things that happen when an application reaches it.
A task has a type, a trigger (`AUTOMATIC` on entry, or `MANUAL` by HR), a recipient
role, and a JSON configuration.

| Task type             | Effect                                                           |
| --------------------- | ---------------------------------------------------------------- |
| `EMAIL_TEMPLATE`      | Send a templated e-mail.                                         |
| `PERSONALIZED_EMAIL`  | Same, but HR fills in custom variables before it goes.           |
| `MS_FORM_EMAIL`       | Send a link to a Microsoft Form.                                 |
| `INTERNAL_FORM_EMAIL` | Send a link to an in-app form.                                   |
| `DOCUMENT_REQUEST`    | Ask the applicant for missing documents.                         |
| `MANUAL_TASK`         | A checklist item for the hiring team.                            |
| `APPROVAL`            | Requires explicit sign-off before proceeding.                    |
| `SCHEDULE_MEETING`    | Schedule a Teams or in-person meeting.                           |
| `DECISION`            | Open a team decision — consent, majority, and the other methods. |
| `REFERENCE_REQUEST`   | Send the applicant a magic link to supply referee contacts.      |
| `REFERENCE_CHECK`     | A manual task for HR to conduct and record a reference call.     |
| `CONTRACT_GENERATION` | Generate a contract from a template.                             |
| `CONTRACT_SIGNING`    | Wait for the contract to be signed.                              |
| `ONBOARDING`          | Send the onboarding form to a hired applicant.                   |
| `TEAMS_NOTIFICATION`  | Post to the configured Teams channel.                            |

Recipients are resolved by **role on the position**, not by name: the applicant, the HR
lead, the hiring manager, assigned team members, the assigned HR staffer, or the person
who created the position. A stage configuration therefore survives people changing jobs.

Stage configuration is `ADMIN`-level (`pipeline:configure`), because a stage change
reshapes every future application. Working the board is `HR_STAFF`
(`applications:move-stage`); managers can work their own tasks
(`applications:manage-tasks`) without holding broader application-edit rights.

## Moving an application

Dragging a card, or moving it from the detail view, applies the target stage's
configured effects. Every move is written to the audit log with who moved it and when,
which is what the time-in-stage and time-to-hire metrics are computed from.

## The application detail view

One page per candidate holds:

* The **profile and answers** to the position's application questions.
* **Documents** — everything they uploaded plus anything you attached.
* **Correspondence** — the full mail thread with the candidate, in both directions.
* **Notes** — internal, never visible to the applicant.
* **Tasks** for this application.
* **Interviews** and **reference checks**.
* The **audit trail**.

## Mailbox integration

A scheduled scan reads the shared HR mailbox over Microsoft Graph and attaches inbound
mail to the matching application, including attachments. Replies you send from the
application go out from the same mailbox, so the candidate sees one continuous thread
and nothing lands in a personal inbox.

If the scan stops attaching or moving mail, there is a dedicated operations playbook —
see [Runbooks](/operations/runbooks). A read-only diagnostic under
**Settings → Integrations** reports credential drift without needing server logs.

## Bulk rejection

When a position closes, the remaining candidates can be rejected in one action. Each
rejection uses the configured template rendered in that person's own locale, and each
one is audited individually.

<Note>
  Bulk rejection is deliberately a separate, explicit action rather than a side effect of closing a
  position. Closing a position never silently mails anyone.
</Note>

## Talent pools

A candidate you would like to keep in mind can be added to a **talent pool** — a named
group you can search and put forward when a matching position opens later.

Membership is **consent-tracked**, not assumed. Each member carries a consent status
with the dates behind it:

| Status    | Meaning                                                         |
| --------- | --------------------------------------------------------------- |
| `PENDING` | Consent has been requested; the candidate has not yet answered. |
| `GRANTED` | The candidate agreed, on a recorded date.                       |
| `DENIED`  | The candidate declined.                                         |
| `EXPIRED` | The consent had an expiry date and it has passed.               |

Consent is requested through a token sent to the candidate, and it expires rather than
running indefinitely — which is the point. Retention beyond a hiring process needs a
basis, and "we kept the CV" is not one. Members remain subject to the same
[DSAR](/guides/admin/audit-and-dsar) rights as any other personal data.

## Search

The pipeline is searchable by name, position, stage and free text. On installations
with AI features enabled, [semantic search](/guides/ai/semantic-search) additionally
finds candidates by meaning — "primary teacher with special-needs experience" — rather
than by keyword match.