Capability
One inbox for everything waiting on your team.
Tasks, risks, issues and milestones are the same object with a different label, which is why this is one module rather than three. The action inbox merges what is assigned to you personally with what is queued to anyone holding a capability — because an approval that only one named person can do becomes a bottleneck the week they are on leave.
Built the way work actually behaves.
Assign to a person or a group
'The Cardiff team' is a valid assignee, so work is not stranded when one person is off sick.
Overdue is computed, not stored
It is worked out at read time from the due date and the status, so it cannot drift away from the truth the way a stored flag does.
Blocking requires an action
An assignee can mark work blocked, but only by giving both a reason and the action needed to unblock it. A block without an action is a complaint, not a hand-back — so blocked work surfaces to the requester, who owns the next move.
Links, not attachments
Work items carry labelled URLs, validated and capped. The platform deliberately does not store files here, which removes an upload and virus-scanning surface entirely.
Append-only status history
Who changed what, and when. Reassignment carries the block state with it rather than quietly clearing it.
Personal data by default
A task linked to a person is part of that person's record: included in their export, deleted on erasure, and fully replaced on pseudonymisation.
Internal does not mean hidden from a subject access request.
This is the misconception the module was built to correct. An opinion recorded about a person is that person's personal data under Article 15. So internal notes are flagged for review when a request arrives, and the default outcome of that review is disclose.
Withholding is possible and requires a reviewer to select a specific statutory ground — third-party data, legal privilege, negotiations, management forecasts, crime prevention, regulatory functions — and to record why. The response tells the data subject that something was withheld and the general grounds, never the content or which note, so they can challenge it if they wish. Review decisions are append-only and cannot be edited afterwards, because that trail is the evidence the request was considered properly.
- Notes are marked external, and visible in the person's own portal, or internal and staff-only
- Seeing internal notes is a separate capability from seeing notes at all, so you can build a role that sees customer-facing history without staff commentary
- Note bodies are fully replaced rather than selectively redacted on pseudonymisation, because free text hides identifying detail no field rule finds reliably
- If somebody is erased while a review of their notes is pending, the erasure wins and the review is cancelled
Derived live, so it cannot lie to you.
Queued items are derived at read time rather than mirrored into a separate table. That is why the inbox can never tell you something is pending after somebody else has already dealt with it — the classic failure of a notification queue that is written once and then forgotten.
Filtering is by capability, by authorship and by category scope, and sorting is by priority and then deadline. You cannot approve your own work, and the filter that enforces that is part of the query rather than a rule somebody is asked to follow.
- Merges 'assigned to me' with 'waiting on anyone who holds this capability'
- Two capabilities only — read and write — deliberately not split further, to keep role design simple
- Typed work items: task, risk, issue and milestone, all carrying blocked state, links, reassignment and data-rights handling unchanged
- Project planning, service management and asset tracking run on this same engine
Questions about work queues
Is this a full service desk?
The queue model, work items, assignment rules, statuses and filters are built, along with messaging rules and retention, external submission to public queues, and the requester's own inbox. Service management, asset tracking and project planning run on the same engine rather than as separate products — they are the same object with a different label.
Why can I not attach a file to a task?
Because storing files here would add an upload and virus-scanning surface for very little gain when a link does the job. Work items carry labelled URLs, validated, count-capped and length-capped. A link on a task about a person is personal data too, so it is included in exports and cleared on pseudonymisation.
What happens to tasks when somebody is erased?
Tasks linked to that person are included in their subject access export, deleted on erasure, and on pseudonymisation both title and description are replaced rather than partially redacted — because free text can hide identifying detail that no field-level rule finds reliably.
Can project work be tracked here?
Yes. Projects carry version-controlled budgets and dates, an append-only owner log, four roles including a sponsor who can see costs as well as the plan, a derived forecast that cannot disagree with the plan, and an interactive plan view. The work engine underneath is the same one, so a project task behaves like any other task — including how it is handled when somebody asks for their data.
Related capabilities
The interesting test of a work model is not the happy path — it is what happens when something is blocked, reassigned and then the customer asks for their data.