Approval Modes

Per entity type you can configure who may approve a draft:

Liberal (Default)

Any user of the tenant may approve. Low friction — suited for master data without high risk.

Consensus

The affected persons must actively agree. Only once enough consents are in does the draft publish.

The affected persons must respond — but silence does not count as approval. A single objection blocks. More pragmatic than full consensus.

Quorum: how many have to respond

By default, Consensus and Consent require every affected person to have responded. That is strict — and in practice it fails on the one person who is on holiday.

You can therefore configure a quorum per entity type: the share of affected persons who must have responded before a decision may be taken at all. Adjustable from “more than half” up to “everyone”; with no setting, “everyone” continues to apply.

Three rules that are deliberately not softened by this:

The threshold only says when a decision may be taken. Which decision applies is still governed by the mode: under Consensus every vote cast must be an approval, under Consent there must be no objection among them.
An objection remains a veto. No threshold overrules it — not even when enough others have already responded.
Silence abstains. It counts neither as approval nor as rejection; it only prevents the quorum from being met. A missing answer is never reinterpreted as a yes.

Rounding is up: 60 % of 5 affected persons is 3, not 2. The draft detail shows the running state — for example “2 of 5 responses — quorate from 3”.

The threshold is recorded when the draft is submitted. If someone changes the configuration afterwards, decisions already under way keep the rule the votes were cast under.

Publishing without a confirmation

Until 09/2026 every publish was confirmed — even the least risky one. Migrating 50 projects meant answering the same question 50 times when there is only one answer; after that you click it away everywhere, including where it means something. A confirmation that protects nothing breaks the confirmations that protect something.

Per entity type you can therefore set “Publish without confirmation”. It is on for new and existing tenants.

It only takes effect under Liberal. Under Highlander a named person has to approve, under Konsens and Konsent others decide — “takes effect immediately” would be a claim about a state that does not exist yet. The switch stays visible in those modes but has no effect, and the interface says so explicitly.

What still asks, regardless of the setting:

Deleting, bulk deletion and restoring
Change comment required — without a dialog there would be nowhere to enter it
a classification change (visibility changes with it)
a deletion that takes more than ten relationships with it
any situation where roleALPHA does not currently know the approval mode

The button says what happens

It used to read “Save & publish” in every situation — and only a failure turned that into “submitted, approval pending” after the fact. Now it names the outcome:

Situation	Button	Afterwards
Liberal, you may approve yourself	Publish	Published
Change comment required	Publish … (the ellipsis announces the question)	Published
Konsens or Konsent	Submit for vote	Waiting for approval
Highlander, you are not the named person	Submit for approval	Waiting for approval
Creating under Konsens/Konsent	Publish	Published

The last row is the special case: a new record is not attached to anything yet, so nobody is affected — it takes effect immediately, even in a Konsens tenant.

Highlander

Only a pre-configured list of persons may approve. Classic for security-relevant areas.

Admin Override

tenant_admin and platform_admin may approve in any mode. So may any role that has been granted the cross-cutting approval:admin permission (see Roles & Permissions) — this lets you hand out the right to approve without full admin rights.

The override only applies within your own tenant. Users who belong to several tenants may only approve in the one they are currently active in and hold the admin role for; for another tenant they have to switch there first. platform_admin and internal system calls are exempt — they work across tenants by design.

Administrators can also skip the draft step entirely in the relationship matrix via a checkbox.

Approval mode configuration per entity type

Where enforcement applies

The configured mode is enforced no matter how the approval reaches the system — a single draft PATCH, a bulk scenario publish, or a fachservice module’s own draft endpoint. A publish that isn’t authorized leaves the draft as submitted rather than silently approving it or discarding the change.

Who are the “affected persons”?

In consensus and consent, not every tenant user decides — only the affected persons, a concrete list of person UUIDs computed once when the draft is submitted and stored as a snapshot on the draft (affectedPersonUuids). “Affected” means: reachable in the entity graph starting from the changed entity, along the configured relationship paths.

The configuration is per entity type in the Traversal section of the approval config (Admin → Entity Types → type → Approval Modes).

How the algorithm resolves affected persons

The traversal configuration consists of up to two phases. Each phase has three parameters:

relTypeIds — which relationship types to follow (e.g. only EXECUTES)
hops — how many steps deep to traverse
direction — forward (along the arrow), reverse (against it), or both

Step by step

Start node: the changed entity (e.g. the role whose description was edited).
Phase 1: breadth-first traversal from the start node up to hops deep. Only edges with the configured relTypeIds and in the configured direction count. All visited nodes form the “phase-1 result”.
Phase 2 (optional): the intermediate nodes from phase 1 (everything except the start) become the new start set for a second traversal. Common use: phase 1 finds all related roles, phase 2 attaches the persons via reverse EXECUTES.
Person filter: from the final node set, only nodes whose entity_type.module = "person" are kept. Deduplicated.
Snapshot on submit: the computed list is stored on the draft exactly once — at submit time. Later graph changes do not modify the list.

Special cases

hops = 0 in phase 1 → only the entity itself is considered (self-approval, if it’s a person). Useful for person master data: “only this person may approve their own data”.
Relationship drafts (creating/editing a relationship): both endpoints are traversed in parallel, the person sets are merged. The effective approval mode is the stricter of the two endpoint entity types (strictness order: Highlander > Consensus > Consent > Liberal).
Create drafts without a scenario: the new entity doesn’t yet exist in the graph, so the person set is empty. In that case the system automatically falls back to liberal — otherwise nobody could approve.
No traversal phases configured: same behaviour as hops = 0, i.e. self-approval only.

Example

Configuration for the Role entity type:

Phase 1: relTypeIds = [IS_IMPLEMENTED_BY], hops = 2, direction = both
Phase 2: relTypeIds = [EXECUTES],          hops = 1, direction = reverse

When the role “Engineering Lead” is changed:

Phase 1: traverse parent and child roles up to depth 2 → “CTO”, “Backend Lead”, “Frontend Lead”, “Platform Lead”, …
Phase 2: from those roles, reverse EXECUTES → all persons who execute one of those roles.
Person filter: only the person entities remain.
In consensus mode all those persons must actively approve before the draft publishes.

Scenarios and Collective Proposals — Deciding several changes as ONE proposal (the strictest mode of all contained types applies)
Drafts — How the draft lifecycle looks
Relationship Types — The relationship types the traversal follows
Persons — Persons as terminal nodes of the traversal
Visibility — Who learns about the draft in the first place

Who learns about a pending decision?

In Konsens and Konsent mode the affected people are notified as soon as a draft is submitted — and reminded while they have not answered. Liberal and Highlander are write permissions, not an approval procedure; nobody is waiting for a decision there, so no notification arises. See Notifications.