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

# The self-service portal

> What applicants and employees do for themselves — on the web and in the iOS app.

The portal is the surface people outside HR actually use. Applicants track their
applications; employees run their own time, absence, documents and pay.

## Signing in

| Path               | Who                                                           |
| ------------------ | ------------------------------------------------------------- |
| Microsoft Entra ID | Staff with a company account, and the iOS app (SSO-only).     |
| Magic link         | Applicants and new hires, before they have a company account. |

A magic link is signed and expires — 60 minutes by default, and seven days for the
onboarding link, because a new hire's first interaction should not be an expiry error.

## What applicants see

<Columns cols={2}>
  <Card title="My applications" icon="folder-open">
    Every application they have made, its current stage, and what happens next in their own
    language.
  </Card>

  <Card title="Open positions" icon="briefcase">
    The careers listing, so they can apply again without leaving the portal.
  </Card>

  <Card title="Document requests" icon="file-arrow-up">
    Exactly the documents a pipeline stage has asked for.
  </Card>

  <Card title="Onboarding" icon="clipboard-check">
    Once hired: the Personalstammblatt and the position's document matrix.
  </Card>
</Columns>

## What employees see

<Columns cols={2}>
  <Card title="Profile" icon="user">
    Their own master data, with the fields they may maintain themselves.
  </Card>

  <Card title="Time tracking" icon="clock">
    Record time, see the week, see the balance against Soll hours.
  </Card>

  <Card title="Leave and absence" icon="umbrella-beach">
    Request, see the balance, see the team calendar for their own team.
  </Card>

  <Card title="Sick leave" icon="notes-medical">
    Report illness, upload the medical certificate, see the salary-continuation entitlement.
  </Card>

  <Card title="Payslips" icon="file-invoice">
    Monthly payslips and the year-end Lohnausweis.
  </Card>

  <Card title="Compensation" icon="franc-sign">
    Their role, band, placement and the recorded rationale — a strict self-view.
  </Card>

  <Card title="Contracts" icon="file-signature">
    Their own contracts, including signing where one is pending.
  </Card>

  <Card title="Certificates" icon="award">
    Request and download work certificates.
  </Card>

  <Card title="Reference requests" icon="envelope-open-text">
    Where the employee has been asked to be a referee for someone else's hire.
  </Card>

  <Card title="Report preferences" icon="sliders">
    What they receive and how.
  </Card>
</Columns>

## How the portal decides what to show

Not from a role scalar, but from facts:

* The presence of an **`Employee` record** unlocks contracts, certificates and
  compensation.
* An open **`PersonalDataForm`** unlocks the onboarding section.
* Applications are always available to the person who made them.

That is why a re-hire keeps a coherent portal: they are the same person, with the same
history, plus a new pre-boarding journey.

## The iOS app

The mobile app is employee self-service: leave, sick leave, time tracking and the
payslip. It is SSO-only, and it talks to the platform through a **versioned API
contract** generated from the same schemas the server validates against — so the app
and the server cannot silently disagree about a payload.

<Card title="Portal API reference" icon="code" href="/api-reference/introduction">
  The endpoints, the DTOs, and the error shapes.
</Card>

## Accessibility

Portal surfaces are built to WCAG 2.1 AA. Every interactive component ships with an
automated accessibility assertion in its test suite — this is a build gate, not a
periodic audit.