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 | ProposedTriagedApprovedIn progressRejected |
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. Unowned open
records surface in the daily attention digest 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 project 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. |
| Delete a comment | Author, or project administrator | You can always remove your own; administrators can remove any. |
| Link and unlink Jira issues | Browse project | Issues are read as the signed-in user, 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. |
| Change project settings | Administer projects | Categories, services, currency, cadences, score weights and approval policy. |
| Delete an improvement permanently | Administer projects | Purges the record, its comments and its entire audit trail. Logged loudly. |
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
Four places in Jira
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. Administrators only.
Issue panel — contribution
On any Jira issue, the improvements that issue contributes to, with status and target date.
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.