Skip to main content
Swiss HR Easy presents one system through three surfaces. Which one a person sees is a product of who they are in the organization, not of how they signed in.

Web dashboard

/dashboard and the module routes beside it. Oriented at HR and management: recruiting, employee master data, payroll, organization — plus functions everyone needs, like feedback, surveys and decisions.

Web portal

/portal. Self-service for applicants and employees: applications, onboarding, contracts, certificates, compensation, time and absence.

iOS app

SSO-only employee self-service — leave, sick leave, time tracking and the payslip. It consumes the versioned portal API.

​
One identity for the whole relationship

A person is one User row for life. There is no separate applicant or candidate record. An applicant is a User with role APPLICANT; on hire, an Employee row is attached to the same user, and every artefact — applications, notes, references, contracts, certificates, compensation — continues to hang off that one identity. This is ADR-011, and it is why the platform can carry a person from a job ad to a work certificate without re-keying anything.
Because identity is continuous, so is the audit trail: a hire’s application history and their employment history are the same person’s history.

​
What each surface shows

1 The portal shows an applicant their own applications only. 2 Time tracking and staff absence are dashboard-group routes that employees also reach, which is why an employee may see dashboard chrome around them.

​
Portal gating

The portal decides what to show from facts about the person, not from a role scalar:
  • The presence of an Employee record unlocks contracts, certificates, and “Lohn & Einstufung”.
  • An open PersonalDataForm unlocks the onboarding section.
  • “Meine Bewerbungen” is applicant-appropriate and always available.
The compensation view is a strict self-view: it never compares the viewer against anyone else. That is a deliberate constraint from the design philosophy.

​
Authentication per surface

The iOS app is SSO-only by decision — a mobile client holding a long-lived magic-link session is a materially worse credential story than a token from the identity provider.
The surface architecture is captured in ADR-012, which is Proposed, not yet accepted. Acceptance is blocked on two access-control findings that the ADR itself records. Treat this page as a description of current behaviour; the routing mechanism may change when the ADR lands.