> ## 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.

# Interviews and reference checks

> Scheduling through Microsoft Graph, and structured reference gathering with versioned question catalogs.

## Interviews

Interviews are scheduled from the application detail view. The platform creates the
calendar event through Microsoft Graph, invites the panel and the candidate, and keeps
the event linked to the application so the record stays in one place.

What is captured:

* **When and where** — including whether it is on site or a Teams meeting.
* **The panel** — interviewers drawn from the position's assigned roles.
* **Notes and impressions** — recorded per interviewer, internal only.
* **Outcome** — feeds the [hiring decision](/guides/recruitment/decisions).

Scheduling is a stage effect as much as a manual action: a pipeline stage can create
the interview task automatically when a candidate reaches it.

## Reference checks

Reference checking is structured rather than ad hoc. Instead of a free-form phone call
recorded in a note, the module sends a referee a set of questions and stores their
answers against the application.

### Question catalogs

Questions live in **catalogs** — a named set for a role type or a hiring context. The
catalog is authored per locale, so a French-speaking referee gets French questions.

Catalogs are **versioned**. When you edit a catalog, existing in-flight reference
requests keep the version they were sent with, and completed checks stay pinned to the
version that was actually answered. This matters: a reference check is evidence in a
hiring decision, and evidence that silently changes shape afterwards is not evidence.

### The flow

<Steps>
  <Step title="Request">
    HR selects referees — usually supplied by the candidate — and picks a catalog. The candidate is
    told which referees are being contacted.
  </Step>

  <Step title="Invitation">
    Each referee receives a magic link to a focused page containing only the questions. They do not
    need an account and they see nothing else about the candidate or the organization's data.
  </Step>

  <Step title="Response">
    Answers are stored against the request, timestamped, with the catalog version.
  </Step>

  <Step title="Review">The hiring team reads the responses in the application detail view.</Step>
</Steps>

### Permissions

Reference checks are `HR_STAFF`+ (`applications:reference-checks`). Managers see the
outcomes on the application, but running the process is an HR responsibility.

### Employees as referees

The mirror case — one of *your* employees is asked to be a referee for someone else's
hire — is handled in the [portal](/guides/portal) under "Reference requests", so the
person answers in a place they already have access to.

<Note>
  Reference data is personal data about **two** people: the candidate and the referee. Both are
  covered by the platform's DSAR handling, and referee contact details are treated as confidential
  to the process.
</Note>