Questions people actually ask

In six places: a project page holding the register, board, dashboard and settings; a project settings page for configuration; an issue panel showing which improvements a given issue contributes to; a global portfolio page that lets you pick which project register to open; a dashboard gadget showing one project’s figures; and a site settings page, opened from Configure in Manage apps, where a Jira administrator decides whether projects may email their attention digest. Where a project turns publishing on, the register can also be found with Jira search.

Yes. It works with Jira and Jira Service Management projects alike — improvements are scoped per project, and the register is the same wherever it is opened.

No. Improvements are scoped per project and configuration is per project, so you can start with a single team, prove it in a service review or two, and expand when it has earned its place.

There is no bulk import in the app today. Registers are usually tens of records rather than thousands, and re-entering them is often the moment the stale rows get retired. If you have a large register to migrate, get in touch and we will talk it through.

Anyone who can browse the Jira project can see the register, raise improvements, edit them, comment and move them through the lifecycle. Changing project settings and permanently deleting an improvement require the Jira "administer projects" permission, and allowing email digests on the site requires Jira administrator permission. There is no separate ImproveDesk user list to maintain.

Not without leaving a trail. Verified can only be reached from Implemented, and verification requires either a realised benefit figure or at least one recorded measure. Every step is an audit event naming who made it and when.

The second write is refused rather than silently overwriting the first. This is the normal case for a register reviewed in a monthly meeting, and a last-write-wins overwrite there quietly loses somebody’s benefit numbers.

A project administrator can. It permanently removes the improvement, its comments and its entire audit trail, and the app says so before you confirm. The deletion itself is kept: Settings lists every deleted improvement with who deleted it and when. Archiving is the reversible alternative: it keeps the record and its history and hides it from the default view.

RICE is the standard formula — reach times impact times confidence, divided by effort. The composite score is configurable: you set three weights per project, applied to the benefit case (forecast against cost), the effort size, and the priority on the record. An improvement nobody has scored returns no score at all rather than zero, so it is never ranked alongside work genuinely assessed as low value.

Any of four reasons. Overdue: it is open and past its target date, with the target day itself treated as inclusive. Stale: it is open and has not been updated within the threshold you configure per project. Due for review: its review date has passed, so its benefit is due to be checked again. No owner: it is open and nobody owns it. All four are derived, so nobody has to maintain a flag, and one improvement can be counted under more than one of them.

Yes. Add the ImproveDesk gadget to a dashboard and choose a project — the list offers projects that have a register and that you can browse. It shows how many improvements need attention, how many are overdue, how many are open and the benefit realised, with the five that have waited longest. Every viewer is checked against the project each time it loads, and somebody who cannot browse it sees a sentence saying so rather than the figures.

Yes, once two switches are on. A Jira administrator first allows email digests for the site, on ImproveDesk’s Configure page under Apps → Manage your apps; it is off until they do. Then a project administrator chooses, in that project’s ImproveDesk settings, weekly or daily, the issue Jira sends it from, up to ten team recipients, and whether each owner is also sent their own items. Jira sends the digest from its own email, and the settings page shows what Jira answered last time.

How many improvements need attention and why, and up to ten of them, longest-waiting first, each by reference with its reason. Titles are included only if the Jira administrator allowed them for the site; by default a digest carries counts and references only. ImproveDesk’s own text never carries a benefit figure, a name or an account id; beneath it, Jira adds the project, key and summary of the issue the digest is sent from, as it does for any notification about an issue. A weekly digest is sent even when nothing needs attention, so that its absence would tell you the check had stopped; a daily one is not. You can preview what the saved settings would send before anything is sent.

Yes, where a project administrator turns on publishing to Jira issues — it is off by default. ImproveDesk then writes a small status record onto each linked issue, searchable with six fields: improvedeskCount, improvedeskStatus, improvedeskStage, improvedeskPriority, improvedeskNextReview and improvedeskOverdue. It carries counts, statuses, stages, the highest priority, the earliest review date and whether any is overdue — no names, account ids, references, titles or benefit figures. Switched off again, what was written is removed by the next daily reconciliation, or straight away with Remove published data.

In Atlassian’s Forge app storage, inside your own tenancy, inheriting your site’s data residency. ImproveDesk has no external service, no vendor database and no analytics endpoint. If a Jira administrator allows email digests, each digest Jira sends is then held by its recipients’ email provider, wherever your organisation’s email is hosted — counts and references only, unless titles are allowed.

No. The app runs in your tenancy and we have no access path to its data.

Reading issues and projects for the linked delivery work, reading user profiles to show people by name and to find an owner or sponsor as you type, reading project permissions to establish what the signed-in user may do, and app storage. The app also declares write access to issues, for three things: the Create delivery issue button on a record, which posts one issue as you; where a project turns publishing on, a small status record on each linked issue; and where email digests are allowed and switched on, asking Jira to email the digest from one issue in the project, which writes nothing to that issue. Each scope is listed with its purpose on the security page.

There is no update path and no delete path for an individual event. The only way to remove history is for a project administrator to delete the whole improvement, which is a deliberate, confirmed action — and the deletion itself is recorded, with who and when, in a log the project’s administrators can see. Events also carry a per-improvement sequence number, so a gap would be detectable.

Yes — export the current filtered view to CSV, 34 columns covering the whole record with account ids resolved to display names. Leading formula characters are neutralised so the file is safe to open in a spreadsheet.

The trend is drawn from a weekly snapshot job, so it needs at least two runs before there is a line to draw. Everything else on the dashboard is computed live from the register and is populated from your first improvement.

Every run is written to a run log, successful or failed, and the register banner states the age of the last sweep. Attention figures that have stopped advancing look exactly like a healthy backlog, so the app tells you rather than letting it hide.