Configuring stages
Under Settings → Pipeline, a stage carries: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.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.
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. 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.Bulk rejection is deliberately a separate, explicit action rather than a side effect of closing a
position. Closing a position never silently mails anyone.
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:
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 rights as any other personal data.