Approval Settings
This page controls a single, company-wide rule: can a person who submitted an HR request themselves (for example a time-off request, an expense claim, or a compensation change) also approve that same request? This is called the four-eyes principle, and it ensures the approver is never the same person as the requester. The rule applies to all matching HR requests across the whole company — there are no per-person or per-department approval chains or hierarchy settings here.
/hr/approval-settingsWhat can I do here?
- See whether the four-eyes rule is currently enabled or disabled
- Turn the rule on or off with a single switch
Step by step
Toggle the four-eyes rule
- Open Approval Settings.
- Flip the switch next to "Enforce four-eyes principle".
- The change saves immediately; a confirmation appears in the top right corner.
Fields explained
| Field | Meaning | Notes/Effect |
|---|---|---|
| Enforce four-eyes principle | Switch that determines whether approvers may approve, reject, or pay out their own HR requests (time off, expenses, compensation) | Enabled (default): self-approvals are blocked server-side. Disabled: only the normal permission check applies, so self-approvals become possible |
Values & statuses
Four-eyes principle
| State | Meaning | What happens |
|---|---|---|
| Enabled | Approvers cannot approve, reject, or pay out their own requests | Another authorized person must handle the request; any attempt at self-approval is rejected |
| Disabled | The four-eyes check is skipped | The four-eyes check is skipped, so anyone with the right permission can also approve their own requests. The responsibility check is untouched by this (see "Responsibility"): cases outside the caller's own line are still refused |
Approval principle per absence type
The switch on this page is the tenant-wide default. In addition, the approval principle can be set per individual absence type, overriding the default. You find this setting in the Absence area under Types, in a type's edit dialog (only relevant when the type requires approval at all).
| Per-type choice | Meaning | Relationship to the tenant default |
|---|---|---|
| Default (tenant setting) | The type follows the tenant-wide switch set above | Existing behaviour, no deviation |
| Two-eyes (self-approval allowed) | For this type an approver may also release their own requests | Overrides an enabled tenant switch for this type only |
| Four-eyes (approver ≠ requester) | For this type self-approval is always blocked | Applies even when the tenant switch is disabled |
In every case the normal approval permission is still required: anyone lacking the permission to approve cannot handle a request anyway. This per-type rule applies to absences only — expenses and compensation still follow the tenant-wide switch alone.
Absence type without an approval requirement
One step earlier there is a second setting in the same place: Requires approval. You find it in the Absence area under Types, in a type's edit dialog. This switch does not answer "who may decide" but "does anybody have to decide at all".
| Type setting | What happens on submission |
|---|---|
| Requires approval (default) | The request is filed as Pending and waits for a decision. Unchanged. |
| Does not require approval | The request is approved right away. The entitlement is booked at the same moment, the shared absence calendar is kept up to date, and nobody lands in an approver queue. |
/hr/absencesSince 28 Aug 2026 this switch actually has an effect. Before that it could be set, yet every request was still filed as Pending and had to be approved by hand. If you set it back then, review it once: from now on it does what its name says.
Existing requests are left alone. Whatever sits in the list as Pending today stays there and still needs a decision. The new rule applies to requests submitted from now on.
It stays traceable nonetheless. Because no human decided here, a request approved this way does not show an empty Approved by field but "automatically (no approval required)". In the audit trail the same event appears with the source System and the reason "no approval required", so a later review can tell it apart from a human decision.
The four-eyes principle does not apply here, and that is not a contradiction: it checks whether approver and requester are the same person. Where nobody approves, that person does not exist. If you want a control for a type, keep the approval requirement on and set the approval principle to four-eyes instead.
Where you see this day to day: when somebody picks a type without an approval requirement while creating a request, the interface says right below the selection that the request applies immediately and the entitlement is booked at once.
Sick notes: the shipped default types "Urlaub" (vacation) and "Krankheit" (sickness) require approval unless you change that. A reported sickness blocks the affected person's appointment availability from submission regardless - no approval is needed for that.
Responsibility: who may decide which case
The toggle on this page answers "may somebody decide their own request". It does not answer
"may this person decide this particular case of somebody else". That is a second, independent
check, and since 26 Aug 2026 it applies to every HR approval path. Absences have had it since
25 Aug 2026.
Before, a permission decided, not a relationship. Whoever held an area's approval permission
could decide any case of any person, across departments, including expense pay-outs and salary
supplements. The four-eyes rule only caught a person's own request; whose case it was otherwise was
never asked.
| Role | Permission | Reach |
|---|---|---|
| HR department | "Manage HR" (hr:manage), plus the owner and super administrator roles |
Decides for all employees of the tenant. HR is nobody's direct line manager and needs that reach. Unchanged. |
| Line manager | the area key only, e.g. "Approve expenses" (hr:expenses:approve) |
Decides only for their own employees, meaning everyone who lists them under the Position tab as line manager or absence deputy. A case outside that line is refused and nothing is booked. |
Which areas does this cover? Every HR decision: absences, benefits (approve, reject, pay out),
expenses (approve, reject, pay out a receipt, approve a report), time tracking (bulk approval,
signing off and reopening a monthly timesheet, approving and rejecting a single entry),
procurement, project time, residence change requests and compensation supplements.
What you need to maintain: every employee record needs a line manager under Position, and
the manager's account must be linked to their own employee record. Without that link the system
cannot tell whom the person manages, and it refuses rather than allows. Check first whether the
employee was invited under HR → Employees and accepted the invitation.
Bulk approvals are all or nothing. If a batch of project or working time contains even a single
entry outside your responsibility, the whole batch is refused and not one entry is booked. That
keeps the record readable: a half-executed bulk approval could no longer be reconstructed from the
log.
Seeing and deciding are not the same. For residence change requests the tenant-wide request
list stays visible to holders of the area key; only the decision itself is limited to the caller's
own line.
Frequently asked questions
Who can change this setting?
Only people with the "hr:manage" permission. Without it, the page is shown read-only.
Which requests does the rule apply to?
HR approve, reject, and pay-out actions for time off, expenses, and compensation, as well as approving self-service profile change requests.
When should I disable the rule?
Only for very small teams where there is just a single person with approval rights and a four-eyes principle isn't practically achievable. For every other team, keeping it enabled is recommended.
Are there different rules per department or multi-step approval stages (e.g. "manager first, then HR")?
Per department or as a multi-step chain: no. This page offers the company-wide on/off switch for the four-eyes principle. For absences, the approval principle can additionally be set per absence type (see the "Approval principle per absence type" section). Multi-level approval chains with different approver types exist instead in Workflow Templates, but those are for automated processes like onboarding — not for ongoing time-off or expense requests.
Can an absence apply without any approval at all?
Yes. Set the absence type in the Absence area under Types to "Requires approval: no". Requests for that type are then approved right away and the entitlement is booked immediately (see the "Absence type without an approval requirement" section). Requests already pending are not affected.
Which takes precedence — the tenant switch or the per-absence-type setting?
The per-type setting takes precedence. An absence type set to "four-eyes" always blocks self-approval — even when the tenant switch is disabled. A type set to "two-eyes" allows self-approval — even when the tenant switch is enabled. "Default" follows the tenant switch.