Everyday use · 4 min read
Delivery issues and the issue panel
How linked Jira issues appear on a record and on the issue itself — and the current limits of the interface.
What a delivery issue is
An improvement says what should change. The Jira issues that actually make the change are its delivery issues. Holding the link means the register can answer "is this moving?" from the delivery work rather than from somebody's recollection.
Read this first. The current interface can show and unlink delivery issues, but it provides no control for adding one. The capability exists in the app's backend and the issue panel is fully built, but no screen calls it. Until that gap is closed, links can only be created outside the interface. The rest of this guide describes what works today and marks clearly what does not.
On the improvement
Where a record has linked issues, they appear in a Delivery issues panel with each issue's key, summary and current Jira status, read live from Jira.
The issues are read as you, not as the app. If a linked issue sits in a project you cannot see, it will not appear — Jira's own permissions still apply, and the register cannot be used to peek at work you are not entitled to.
Unlink removes the association. It does not touch the Jira issue itself, and the removal is written to the audit trail.
If a record lists issue keys but the panel says the issues could not be read from Jira, that is usually a permission difference rather than a fault — somebody with wider access linked work you cannot see.
On the Jira issue
The other half is a panel on the issue itself, headed Continual Improvement. It answers the question the person doing the work actually has: why am I being asked for this?
Each entry gives the reference, the title, the category, the target date and the current status. Where the improvement is overdue, that is shown too.
If an issue contributes to nothing, the panel says so plainly rather than rendering an empty box.
What happens automatically
Two Jira events are handled without anybody doing anything, which is what stops the links quietly rotting.
| When this happens in Jira | ImproveDesk does this |
|---|---|
| A linked issue is deleted | Removes the link from every improvement that held it, and records the removal in each audit trail. Without this you would accumulate references to issues that no longer exist. |
| A linked issue is resolved | Writes an audit event on each improvement noting that the issue was resolved. It does not transition the improvement. |
Why resolving an issue does not advance the improvement. Finishing the delivery work is not the same as the improvement having worked. Moving a record to Implemented — and later claiming a benefit for it — is a judgement that belongs to its owner, so the app records the fact and leaves the decision alone.
Working around the gap today
Until linking is exposed in the interface, the practical options are:
- Reference the improvement from the Jira issue. Put the reference —
CSI-12— in the issue summary or description. It will not populate the panels, but it survives and it is searchable in Jira. - Search the register by issue key. Where links do exist, the register's search
matches linked issue keys, so pasting
OPS-412finds the improvements it belongs to. - Record the delivery work in the description or a comment as an interim measure, so the association is at least written down.
A limit worth knowing
Issue keys are validated for shape but not for project. A key from another Jira project can be stored against an improvement. That is deliberate — improvements are often delivered by another team's board — but it does mean a typo can produce a link to a real issue somewhere unexpected. Because the issues are read with your own permissions, nothing is disclosed that you could not already see.