How to revert
- Run a report on the Changes tab (in the activity view), or open a work item’s History+ tab.
- Tick the rows you want to undo. The tick box in the header selects everything on the current page that can be reverted. Rows that never can (comments, attachments, links, time tracking, the Created row, and changes that changed nothing) have no tick box; hover the empty box for the reason. In a work item’s panel, a comment row links to its Comment history instead.
- Press Revert n selected (on a work item, Revert n).
- The Revert preview opens and checks every selected change, showing Checking OPS-12 (3 of 40)… as it goes. Nothing has been written yet.
- Read the table, then press Revert n changes.
- The results table replaces the preview. Press Download CSV for a record. Behind the dialog the report runs again, so the table shows the work items as they are now, including the revert itself.
To undo a whole automation run, tick Bulk changes only in the filters, select the rows and revert them together. See the BULK badge in Reports and the explorer.
The dry run
Before anything is written, the app reads each affected work item once and works out, per change:
| Status | Meaning |
|---|---|
| Ready | The field still holds the value that this change set, and the app knows how to write the old value back |
| Conflict | The field has changed again since. The current value is shown so you can decide what to do |
| Not revertible | The field cannot be written back through the Jira API, with the reason |
The summary line reads, for example: 43 can be reverted · 5 changed again since · 2 can't be reverted. Nothing has changed yet.
Each ready row shows what will happen, written as current value → value restored, for example Status: Done → In Progress. Reverts of rich-text fields (Description, Environment and multi-line custom fields) carry the warning Formatting may differ from the original.
Conflict detection
A revert is only offered when the field still holds what the change set. The check is per field type:
- Text is compared after trimming; rich text is compared as plain text, ignoring formatting markers.
- Numbers are compared numerically, dates by day, date-times by instant.
- Single-value fields (priority, work item type, parent, select lists) are compared by ID, falling back to the display name.
- Lists (labels, multi-select, multi-user) are compared as sets, so the order does not matter.
- Components, fix versions and affects versions are checked per value: reverting an addition requires the value to still be present, reverting a removal requires it to still be absent.
- Status is compared by status ID, where Jira recorded one.
If the check fails, the row becomes a conflict and is skipped. Reverting a conflicted row would silently discard whatever happened in between, so the app refuses.
The check runs twice. The preview checks everything up front, and then, when you press Revert, each work item is read again and re-checked immediately before it is written. Someone else’s edit made while the preview sat open is caught, not overwritten.
Fields that can be reverted
| Field | How it is written |
|---|---|
| Summary, single-line text and URL custom fields | Set directly, or cleared if the old value was empty. A summary cannot be cleared, because Jira requires one |
| Description, Environment and multi-line text custom fields | The old plain text is written back as paragraphs |
| Labels and other text lists | The whole old list is set |
| Assignee, Reporter, user pickers | Set by account ID, or cleared |
| Priority, work item type, parent, select lists | Set by ID, or by name where the option still exists |
| Due date, date and date-time custom fields | Set to the old value, or cleared |
| Number custom fields | Set to the old number, or cleared |
| Components, fix versions, affects versions | The single value that was added is removed, or the value that was removed is added back |
| Multi-select and multi-user custom fields | The whole old list is set |
| Sprint | Moved back to the previous sprint, or cleared, unless that sprint is closed. If the work item was in several sprints, only the last is set, and the preview says which others it was in |
| Status | Performed as a workflow transition whose target is the old status |
Fields that cannot be reverted
| Field | Reason |
|---|---|
| Project | Moving a work item to another project cannot be undone from history |
| Key | The key only changes when a work item moves project |
| Comment | Comments are edited or deleted on the work item, not reverted |
| Logged work, time tracking, estimates | These come from worklogs and estimates, and are adjusted on the work item |
| Links, remote links | Links are added and removed on the work item, not through history |
| Attachments | A deleted attachment cannot be recovered |
| Created, Creator | Set by Jira |
| Flagged | Jira does not allow the flag to be set through the edit API. Toggle it on the board |
| Resolution | Set by the workflow. Revert the status instead |
Other cases appear as not revertible when they apply to your site:
- Not editable on this work item’s edit screen. The field is not on the edit screen for that project and type, so Jira will not accept a write.
- No workflow transition from X back to Y. The workflow offers no route from the current status to the old one. Add a transition, or move the item by hand.
- “X” is no longer an available value. The option has been removed from the field since the change.
- Unsupported field type. Field types the app cannot write back safely, such as cascading selects, group pickers and version pickers in custom fields.
Permissions
Reverts run in your browser as you, using your own Jira session.
- Jira enforces your own permissions on every write: edit for a field, Transition work items for a status. If you don’t have the one a row needs, the revert fails for that row and the reason is recorded.
- Workflow conditions, validators and post-functions apply to a status revert exactly as they would if you clicked the transition yourself.
- The change appears in Jira’s own history under your name, not under the app’s. That is deliberate: an audit trail should name the person who made the decision.
- An administrator can limit who may use revert at all. See Admin settings.
Results and the CSV
Changes are written one at a time, so a rate limit or a single failure never takes the whole batch down. The results table shows Success, Failed or Skipped per row, with Jira’s message on a failure and the reason on a skip (for example Changed again since (now: High)), and the summary line reads, for example, 41 reverted · 0 failed · 7 skipped.
The CSV has seven columns:
| Column | Contents |
|---|---|
| Work item | Key |
| Field | Field label |
| Change | What the revert did, for ready rows |
| Plan | ready, conflict or unsupported |
| Outcome | Success, Failed or Skipped |
| Details | The error, the block reason, or the warning |
| Event ID | The change’s identifier, so a row can be traced back to the report |
You can download the CSV from the preview as well as from the results, which gives you a record of a dry run you decided not to execute.
Limitations
- Rich-text formatting cannot be restored. Jira’s history keeps plain text only, so a reverted description comes back as paragraphs of text.
- Reverting does not delete the intervening change. Jira’s history keeps both, and the revert is recorded as a new change made by you.
- A revert cannot recreate a comment, an attachment, a link or a worklog.
- Sprint reverts cannot move a work item into a closed sprint, because Jira refuses that.
- Reverts run sequentially, so a very large batch takes time. The progress line shows how far it has reached.
- There is no undo for a revert. Run a second revert from the new history rows if you need to go forward again.