Approvals
Multi-stage approval workflows with the four-eyes principle for DPIA, TIA, Annex IV and further records.
Some records should not be completed by the person who created them. With approvals, an administrator defines per object type who has to agree, and in which order, before a record reaches its final status. While a workflow is active, completion cannot be set without an approval, neither in the interface nor through the API.
At a glance
- Included from
- Available in all plans as soon as the module concerned is booked (beta)
- Where in the app
- My approvals (inbox); set-up in the settings
- Output
- Approval history with stages, decisions, comments and timestamps in the audit log
- Legal basis
- Accountability (Art. 5(2), Art. 24 GDPR); QMS approvals (Art. 17 AI Act)
What can be approved
Six object types. For each, the approval guards the move into the final status.
| Object | Guarded transition |
|---|---|
| DPIA (Art. 35 GDPR) | Approval status → APPROVED |
| Transfer impact assessment (TIA) | TIA status → ABGESCHLOSSEN |
| Vendor onboarding | Onboarding status → FREIGEGEBEN |
| Technical documentation (Annex IV) | REVIEW → APPROVED; requesting moves a DRAFT dossier to REVIEW |
| EU declaration of conformity | Confirmation of the declaration |
| Compliance checklist (high risk) | Status → COMPLETED |
How a workflow is set up
Administrators set up workflows, exactly one per object type:
- Up to three stages, run one after another.
- Per stage, named people (up to 20) and/or a role (admin, editor, viewer). A role is resolved, when the approval is requested, into the people holding it at that moment; later role changes do not affect running approvals.
- Per stage the rule "one person suffices" (ANY) or "everyone must approve" (ALL).
- A workflow can be switched on and off. Without an active workflow the previous behaviour without approval applies.
Four-eyes principle
By default, neither the person requesting the approval nor the person who created the object may decide on it. The four-eyes principle can be switched off per workflow. If a stage is left without an eligible person as a result, the app refuses the request immediately instead of leaving it hanging.
How an approval runs
- 1Whoever may edit the object requests the approval in the object’s approval panel, optionally with a comment.
- 2The people of the first stage receive an e-mail and see the request under "My approvals".
- 3Once a stage is complete, the next one opens. A single rejection rejects the whole request; a rejection always needs a reason.
- 4After the last stage, SimpleAct sets the object’s final status, with the same checks as when set by hand. If a check fails, the approval stays available and completion can follow once the gap is fixed.
- 5The requester receives an e-mail with the outcome. They or an administrator can withdraw a running request.
Good to know
- Each approval is consumed exactly once. If an object is completed again later, it needs a new approval.
- Creating an object directly in its final status is not possible while a workflow is active.
- Approvals are personal decisions: they only work with a signed-in session, not with an API key. If the API tries to set a guarded completion without an approval, it answers 400 with rule.approval_required.
- Without configured e-mail delivery, "My approvals" shows the same requests; a failed e-mail never undoes a decision.
- Approvals in governance (evidence approvals per AI system) are a separate, older mechanism and run independently.