HR governance

FixControl can answer employees' HR questions under a permission model you control. It does not become your HR chatbot, your HR master-data system, your document repository, or your operational service desk. It decides who may ask, what they may be answered from, how sensitive the question is, who may read the case, who has to approve the answer, and what is recorded.

This page is the administrator's view. The employee's view is HR questions.

Switching it on

HR answering is off by default. Existing projects change in no way until you enable it.

Open the project → HR governance settings card (also available at GET/PUT /api/projects/<id>/hr/settings). It is gated by the project.settings.manage project permission, like other project settings.
Set Enabled. Only projects you explicitly enable can process HR questions.
Set the auto-answer threshold — the confidence a general policy answer needs before it can be delivered directly. Below it, the question becomes a draft or a review case.

A project that isn't enabled is invisible to the whole HR path. A question asked against it isn't refused with an explanation of what exists — it simply falls through to the normal intake flow, and nothing about HR is revealed.

Project roles and HR permissions

HR permissions are project permissions. They are not attached to any tenant role, so being a tenant administrator, a platform administrator, or a technical administrator gives you no HR content access at all. Every HR action requires an active membership of the project.

Hand out permissions through project roles. These are the ones that matter:

Permission	What it allows
`hr.case.create`	Ask an HR question at all. Employees need this.
`hr.case.read_own`	Read your own questions, cases and answers.
`hr.case.read_assigned`	Read normal-sensitivity cases in the queue.
`hr.case.read_sensitive`	Read a restricted case — and only when explicitly assigned to it.
`hr.case.respond`	Work a case: draft, respond, mark an answer incorrect within readable scope.
`hr.case.assign`	Hand a case to a reviewer. Sees restricted cases as metadata only.
`hr.case.approve`	Decide an approval on an answer.
`hr.case.escalate` / `hr.case.close`	Escalate or resolve a case. For a restricted case, only its assignee may do this.
`hr.communication.draft` / `.approve` / `.send`	Draft an answer, approve it, deliver it.
`hr.employee.read_self` / `.read_limited` / `.read_sensitive`	How much employee data this role may see.
`hr.payroll.read` / `hr.medical.read_restricted`	Payroll and medical content, separately grantable.
`hr.audit.read`	Read the HR audit trail.

Project settings and membership management (project.settings.manage, project.members.manage) are administration, not content. A project administrator can enable HR and manage the roster and still see no case, answer, task or audit line.

A worked role set

The demo tenant seeds a role set that shows the intended separation. Copy the shape, not the names:

Role	Idea
Employee	Ask questions, read own cases, see own minimal data. Nothing else.
HR Service Desk	The normal queue, responses, limited employee data. No sensitive cases, no approving, no assigning.
HR Advisor	Sensitive assigned work, assigning, approving, escalating, closing, delivering, reading the audit trail.
Payroll	Assigned work plus payroll data. Deliberately no sensitive-case access.
Confidential Advisor	Explicitly assigned sensitive work only — deliberately without `hr.case.read_assigned`, so this role never sees the general queue.
Project Administrator	Settings and membership. No HR content.
Technical Administrator	Technical project and connection metadata. No HR content.

Seed a second reviewer with approval rights from day one. Four-eyes means a single approver blocks themselves.

Sensitivity levels and the assignment bridge

Every question carries one of three levels: NORMAL, SENSITIVE, HIGHLY_RESTRICTED. Medical or absence, legal or compliance, and confidential employee-relations content take a restricted route. Classification is rule-based first; an AI proposal may raise the level or add a review requirement on top, and can never lower either.

The level decides who may read the case, and assignment is the bridge between a case existing and someone being allowed to work it:

Someone with hr.case.assign sees a restricted case as metadata only — status, sensitivity, route. The summary is not readable to them.
They may hand the case only to an active project member whose role carries the permission that case's sensitivity requires: hr.case.read_assigned for a normal case, hr.case.read_sensitive for a restricted one. You cannot assign a confidential case to someone who would then be allowed to read it because you assigned it.
Assignment moves new or waiting work to triaged, bumps the case version, and is recorded.
Closing or escalating a restricted case additionally requires being its assignee — not merely holding the permission.

Normal-sensitivity cases can be mirrored to an allowlisted service desk, and then only as a masked title plus a classification label — never the question text. Restricted cases are never mirrored.

Four-eyes approval, expiry, and delivery

An approval is a snapshot: the answer text and version, the recipient, the case, the source versions used, the policy decision, the classification, and a content hash.

Four-eyes is enforced at the chokepoint. Whoever requested an approval can never decide it. There is no setting that relaxes this.
A changed answer voids the approval. The decision is compared against the current hash and version.
Approvals expire after 72 hours, server-side. Clients cannot choose or extend the window.
Delivery consumes the approval in a single conditional step, so a double click or a replayed request cannot deliver twice. The answer is then marked delivered.
A repeated decision is idempotent, so a retry is a status, not a second decision.

Answers about someone's own situation are draft-or-review by policy. Only a current, authoritative, non-contradicting general or procedural source above your confidence threshold can be delivered directly. Missing, expired or conflicting sources, an unavailable connection, low confidence, and unclear intent each route to a person rather than to a guess — that routing is recorded with a reason code.

Correction and withdrawal

The person who asked, and HR staff within the scope they may already read, can mark an answer incorrect. The answer goes under review, the original row is preserved, and a correction plus review task is created.

Publishing a correction creates a new version, marks the old one superseded, links the lineage, and resolves the task. It never overwrites the original.
Withdrawing is the no-safe-replacement path: the original is kept and marked retracted, and the correction closes as retracted.

Connecting AFAS Profit and Visma Raet Youforce

Both connections are read-only. They read a small, named set of fields and write nothing back to your HR system.

Activation is two-sided. Credentials make a connection available to the tenant; the project must additionally list that connection as active before FixControl will use it. An unconfigured tenant simply has no such connection — it does not error, and no project can accidentally start reading from a system nobody configured.

Credentials are per tenant. The preferred source is the tenant's own connection entry (type afas or youforce), whose token is encrypted at rest. Central platform settings remain as a fallback for deployments configured before per-tenant storage existed. A partially filled entry — a token without a base URL, or a secret without a client id — is ignored rather than merged with central values, so one environment's credential can never be paired with another environment's host.

System	What it needs
AFAS Profit	An app-connector token and your ProfitRestServices URL, plus three GetConnector views you define in AFAS with prescribed field ids (employee, leave, payroll).
Visma Raet Youforce	An OAuth2 client id and secret, the token endpoint, the domain-API base URL, and three endpoint templates. Templates must stay on the same host as the base URL, over https — a foreign host or an unresolved placeholder is refused before any request is made.

The field ids are prescribed, never guessed: employee id, e-mail, employment percentage, employment type, collective agreement; remaining leave hours with an as-of date; a payroll explanation code with an as-of date. If your system names fields differently, map them in your own view or API gateway. Every call filters on one person and projects the response onto that fixed shape, so widening a view on your side cannot leak extra personal data into an answer.

Failure is honest. A missing record, an unparseable value, an unexpected response shape, or an unreachable endpoint all route the question to a person and record a reason code. No number is invented, and a leave balance is never defaulted to zero. Error messages carry a stable code and at most an HTTP status — never a token, a URL, a response body, or an e-mail address.

Health is visible before an employee hits it. Both connections run a periodic connection check — for AFAS a filtered read that can match no employee, for Youforce a forced token refresh — so a revoked token or rotated secret surfaces as a failing check, an audit event, and an administrator notification rather than as a failed answer. Only the connection is checked; a single missing employee record is a data condition, not a broken integration, and does not colour the connection red for everyone.

What the AI may and may not do

The model receives the question text only, to propose a classification, and that call runs outside the tenant transaction. Personnel data, retrieved documents, and answer bodies are never sent to a model; answers themselves are drafted from templates and server-selected sources.

The model has no database access and no free HTTP tool. It cannot resolve identity, grant membership, lower a classification, choose source ids, reach a connection, evaluate the policy, approve, or deliver. Source references on an answer come only from rows the server selected, so a model-supplied source id is never trusted. If the provider is unavailable, the rule-based route is used and the question keeps moving.

Audit and privacy

HR audit events record the tenant and project scope, aggregate identifiers, classifications, source ids and versions, the policy decision and its reason code, and a correlation id. They deliberately exclude question text, medical content, case summaries, employee references, and answer bodies — that content stays in the HR tables under fail-closed row-level security.

Operational metrics use bounded values only (question type, decision, whether a conflict or failure occurred, duration). They carry no user, employee, tenant, project, case or connection labels.

Rolling back

Disable the project setting first, drain the review work in flight, and export any governance references you need before removing the HR tables. Removing the per-tenant connection entries costs you the per-tenant credentials, not the capability — the connections fall back to the central settings.

Known limits worth planning around

The governance texts an employee sees (the status line, the answer, a clarifying question) are Dutch-only today. That also applies to the chatbot API, which answers Dutch governance text regardless of the requested locale. The chat adapters' own surrounding copy is EN and NL.
There is no connection form page for AFAS or Youforce yet. Entries are created through the generic infrastructure API, and there is no Settings → Integrations card for them.
A rotated credential is picked up on the next connection build. For Youforce, rotating only the secret leaves a cached access token valid for the rest of its lifetime, because the cache is keyed by token URL and client id.
Approval and assignment actions are available on the HR board; reviewer-team notification SLAs on top of the assignment lifecycle are not built.
Retention and erasure jobs for restricted HR rows are not built — plan those under your own privacy schedule.

HR questions — the employee's view.
Governance & policy — the org-wide policy engine.
Users & roles — memberships and project roles.