Workflow & roles
The lifecycle is the control
Nine statuses, a strict transition graph, and two configurable approval gates. This is what turns a list of good intentions into evidence: an improvement cannot claim a realised benefit unless it actually travelled the route that earns one.
The happy path
Plan, Do, Check, Act
Each status maps onto a stage of the Deming cycle. The stage is stored on the record rather than derived at read time, so historic improvements keep the mapping they were managed under even if the model later changes.
The whole graph
Every permitted transition
Anything not in this table is refused by the server, not merely hidden in the interface. A client that asks for an illegal move gets a structured error naming the transition it attempted.
| From | Deming stage | May move to |
|---|---|---|
| Proposed | Plan | TriagedRejectedOn hold |
| Triaged | Plan | ApprovedRejectedOn holdProposed |
| Approved | Plan | In progressOn holdRejected |
| In progress | Do | ImplementedOn holdRejected |
| Implemented | Check | VerifiedIn progress |
| Verified | Check | ClosedIn progress |
| Closed | Act | Terminal — nothing follows a closed improvement. |
| Rejected | Act | Proposed |
| On hold | Plan | The status it was held fromRejected |
Verified needs implemented
There is no route to Verified that does not pass through Implemented. This is precisely what makes the realised-benefit figure on the dashboard defensible rather than aspirational.
Reopening clears the stamps
Moving back from Implemented or Verified clears the downstream completion timestamps, so no record can ever show a verification date that precedes its implementation.
Rejection needs a reason
An improvement cannot be rejected without one, and it is kept in the audit trail. If the record is later reopened the reason is cleared, so a live improvement never carries a stale rejection.
Approval gates
Three gates on the way through
The first two are optional project policy, and both are enforced from Approved onwards — so they gate approval, implementation, verification and closure alike, rather than being a check that can be satisfied and then undone. The third is always on.
Require an owner before approval
Optional policy
An improvement with nobody's name against it does not get approved. Open improvements
with no owner are counted on the register's attention banner either way.
Require a benefit case before approval
Optional policy
Either a forecast figure or a written narrative. It stops "we should probably do this"
reaching the approved column without anyone saying what it is worth.
Evidence before verification
Always enforced
An improvement cannot be verified without either a realised benefit figure or at least
one measure recorded against it. Verification is the claim that it worked, so
ImproveDesk insists on something that shows it did.
Accountability
Three names on every record
| Field | Who it names |
|---|---|
| Owner | The person accountable for making the improvement happen. Can be required before approval by project policy. |
| Sponsor | The person accountable for the benefit being realised — typically the service or business owner. |
| Raised by | Stamped by the server from the signed-in account. Never accepted from the client. |
These are accountability fields, not permission gates. ImproveDesk deliberately does not invent its own permission system — it uses the Jira permissions you already administer.
Roles & permissions
Your Jira permissions, nothing new to administer
ImproveDesk has no user list, no role editor and no separate access model. Every action is gated on a Jira permission that your administrators already manage, and the check is made against Jira on each request.
| Action | Requires | Notes |
|---|---|---|
| View the register, board and dashboard | Browse project | Anyone who can see the Jira project can see its improvements. |
| Raise an improvement | Browse project | Improvement is stamped with the raiser’s account by the server. |
| Edit an improvement | Browse project | Every edit writes a field-level audit event. |
| Move an improvement through the lifecycle | Browse project | Only transitions the graph permits are offered or accepted. |
| Comment | Browse project | Comments are attributed and timestamped. |
| Link and unlink Jira issues | Browse project | The issue is read as the signed-in user when it is linked, so Jira’s own permissions still apply. |
| Archive an improvement | Browse project | Reversible. Keeps the record and its history, hides it from the default view. |
| Export to CSV | Browse project | Exports the current filtered view. |
| See a project’s figures in the dashboard gadget | Browse project | Checked for each viewer every time the gadget loads. Anyone else sees a sentence saying they have no access, not the figures. |
| Change project settings | Administer projects | Categories, services, currency, cadences, score weights, approval policy, publishing to Jira issues and the email digest. |
| Delete an improvement permanently | Administer projects | Purges the record, its comments and its entire audit trail. The deletion itself — which improvement, who, when — is kept in the deletion log on Settings. |
| Allow email digests on the site | Administer Jira | The site settings on ImproveDesk’s Configure page: whether any project may send a digest, and whether a digest may carry titles. |
Permission checks fail closed. If the Jira permissions endpoint returns anything other than success, ImproveDesk treats the answer as "no permission" and logs it loudly. An endpoint that quietly starts failing must never become an open door.
Where it appears
Six places in Jira
And, where a project switches publishing on, in Jira search itself: the register's status is written onto its linked issues, so a JQL query can find it.
Project page — the register
The main surface. Register, board, dashboard and settings for a single project.
Project settings — configuration
Categories, services, currency, cadences, weights and approval policy, publishing to Jira issues, the email digest, and the log of deleted improvements. Administrators only.
Issue panel — contribution
On any Jira issue, the improvements that issue contributes to, with status and target date.
Dashboard gadget — at a glance
One project's figures on any Jira dashboard: needing attention, overdue, open and benefit realised, with the five improvements that have waited longest. Each viewer is checked against the project every time it loads.
Site settings — the Configure page
Under Apps → Manage your apps, for Jira administrators: whether any project on the site may email its attention digest, and whether a digest may carry titles.
Global page — the portfolio
A global page has no project in its context, so ImproveDesk asks which register to open — and permission-checks every project in that list individually. The list is the projects that hold improvements, not the projects you are entitled to see; those are two different things, and ImproveDesk treats them that way.
How this maps to the standards
ITIL 4's continual improvement practice, ISO/IEC 20000-1 clause 10.2 and 9.3, and ISO/IEC 27001 clauses 10.1 and 10.2.