Approval task report
Lists approval tasks — one row per task — together with who requested the change, who it was
requested for, who decided it and how. Intended for auditing approval activity: "what did this
person approve last month", "what is still waiting on this approver", "which requests did this
department raise".
The report only contains tasks the executing user is allowed to `READ`.
Report fields
| Column | Meaning |
| Task name | Human-readable task name as shown in the task list, resolved from the workflow event type and localized to the executing user's language. |
| Requester | Identity that created the request the task belongs to. |
| Requested for | Identity the request is for (the applicant). For tasks that create an entity rather than modify an identity (e.g. technical account creation) the created entity's name is shown instead. |
| Created | When the task was created |
| Current approvers | Identities that can decide the task, comma separated. Only filled for running tasks. |
| Decided by | Identity that approved or rejected the task. Empty while the task is still running. |
| Request | Id of the request the task belongs to. |
| Delegation | 'Yes' when any of the task's identity links has a delegation - equivalent to the delegation symbol appearing in the approval tasks agenda |
| State | Task state (e.g. `RUNNING`, `APPROVED`). |
| Approval process id | Id of the workflow instance that the task belongs to. |
| Link | Link to the task detail in the frontend ('/task/wfe{id}/'), built from the configured frontend url |
| Decision | The decision taken (e.g. `APPROVE`, `DISAPPROVE`). Empty while the task is still running. |
| Decided | When the task was decided. Empty while the task is still running |
| Decision Note | Approval task note added by the approver when deciding the task. Empty for tasks not yet decided. |
| Event type | Code of the workflow event that produced the task. |
Filter fields
| Field | Type | Meaning |
| Decided by | Identity | Only tasks decided by this identity |
| Approvers | Identity | Only tasks that have the given identity in their current approvers (if multiple are selected, the resolution is ANY OF) |
| Approval Task state | State | The state(s) of the approval task (RUNNING/APPROVED/DISAPPROVED…) |
| Requester | Identity | Only tasks of requests created by this identity |
| Applicant | Identity | Only tasks of request for this identity |
| Approved / rejected from | Datetime | Only tasks decided at or after this moment |
| Approved / Rejected till | Datetime | Only tasks decided at or before this moment |
| Created from | Datetime | Only tasks created at or after this time |
| Created till | Datetime | Only tasks created at or before this time |
| Created in last X days | Number | Only tasks created within the last X days, counted back from the moment the report runs |
| Decided in last X days | Number | Only tasks decided within the last X days, counted back from the moment the report runs |
Combining absolute dates with "last X days"
Created in last X days and Decided in last X days*are relative lower bounds, counted back from
the moment the report runs. They do not overwrite the corresponding absolute from field. The
two are combined and the stricter (later) of the two win*, since the stricter bound is already
contained in the looser one.
For example, running the report on 2026-07-10 with Created from = `2026-01-01` and Created in last
X days = `7` returns tasks created on or after `2026-07-03`. The upper bound (Created till) is
unaffected in either case.
Known issues
- When using only the filter decidedBy/decidedFrom/decidedInLastXDays the report can be very slow since this filter isn't yet natively implemented - the executor has to retriete all the tasks and then filter them manually
- The createdBy and decidedBy filters when given a certain day understand the day as an exclusive bound