DEV Community: Aleksander

I Tested a Jira Automation Rule for Deleted Work Items. Here Is What It Actually Saves

Aleksander — Fri, 16 Oct 2026 10:55:54 +0000

Short answer: A Jira Cloud automation rule with the Work item deleted trigger and a Send email action is worth adding. In my test it captured the key, summary, description, status, assignee, reporter, labels, dates, linked keys, subtask keys, total time spent and, importantly, who deleted the item, even on the Free plan, which has no audit log. It did not capture comment text or individual worklogs, and the attachment link in the email returned 404 because the file is deleted with the work item. Use the rule as an alert and a copy of the basics, not as a backup.

I tested this on October 16, 2026, on a Jira Cloud Free site with a team-managed project. Below are the exact setup, the email template I used, and what arrived.

Why bother with a rule

Jira Cloud deletes work items permanently. There is no recycle bin for them, and Atlassian Support cannot restore a single deleted work item. I covered the recovery options in an earlier post.

An automation rule does not prevent deletion or undo it. What it gives you is a record created at the moment of deletion: an email (or Slack message) with whatever the rule could read from the work item. If someone deletes the wrong ticket, you know right away, you know who did it, and you have something to rebuild from.

Setting up the rule

Open the project, then Project settings → Automation, and click Create rule.
Choose the trigger Work item deleted. It has no settings.
Add the action Send email.
In To, add your own address or a shared mailbox. In Subject, use something searchable, for example:

   Deleted: {{issue.key}} {{issue.summary}}

On the content tab, switch the format to Plain text. In rich text mode, smart values have to be wrapped in inline code, which is easy to get wrong.
Paste the template below, then click Save and enable and give the rule a name.

A project rule only covers that one project. If you want every project covered, you need a rule with a wider scope, created in global automation settings by a Jira admin, if your plan allows it.

The email template I used

Key: {{issue.key}}
Summary: {{issue.summary}}
Type: {{issue.issueType.name}}
Status: {{issue.status.name}}
Priority: {{issue.priority.name}}
Assignee: {{issue.assignee.displayName}}
Reporter: {{issue.reporter.displayName}}
Deleted by: {{initiator.displayName}}
Created: {{issue.created}}
Updated: {{issue.updated}}
Labels: {{issue.labels}}
Parent: {{issue.parent.key}}
Due date: {{issue.duedate}}
Description:
{{issue.description}}
Attachments: {{issue.attachment.filename}}
Links: {{issue.issuelinks.outwardIssue.key}} {{issue.issuelinks.inwardIssue.key}}
Subtasks: {{issue.subtasks.key}}
Time spent: {{issue.timetracking.timeSpent}}
URL: {{issue.url}}

I also tried the comment smart values from Atlassian's documentation, {{#issue.comments}}{{author.displayName}}: {{body}}{{/}} and {{issue.comments.last.body}}. They are left out of the template above because they came back empty. Details below.

How I tested it

I ran two tests.

Test 1. A work item with a description, a label, an assignee, one comment, one worklog of 1 hour, one attachment, a "relates to" link to another work item, and one subtask. I deleted it together with its subtask.
Test 2. A work item with a description, two comments, one worklog of 30 minutes, and one attachment.

Each email arrived within a few seconds of the deletion.

What arrived and what didn't

Value	Result
Key, summary, type, status, priority, reporter, created, updated, labels, URL	Arrived
Assignee	Arrived (empty if the item was unassigned)
Who deleted it (`{{initiator.displayName}}`)	Arrived, also on the Free plan
Description	Arrived as plain text
Comment text	Did not arrive. In test 1 the comment loop returned the author's name with an empty body. In test 2 the comment count was 0
Individual worklogs	Did not arrive. Only the total time spent ("1h", "30m") came through
Attachments	File name and size arrived. The attachment URL in the email returned 404, because the file was already deleted
Linked work items	The linked key arrived. The link itself was removed from the other work item
Subtasks	Subtask keys arrived in the parent's email
Subtask's own email	Each deleted subtask triggered its own email. Its Parent field was empty, because the parent was deleted in the same operation

The useful surprise is Deleted by. On the Free plan there is no audit log, so the email may be the only record of who deleted a work item. On paid plans the audit log records it too, but an email is easier to search and arrives immediately.

The disappointing part is comments. On many teams the comments are the most valuable part of a ticket: decisions, reproduction details, answers from customers. The rule did not give me any comment text after deletion.

Things to know before you rely on it

It only covers deletions after you create it. It cannot tell you anything about a work item deleted yesterday.
Bulk deletes mean bulk emails. Every deleted work item, subtasks included, runs the rule and sends one email. If someone deletes 200 items, you get 200 emails. Consider a dedicated mailbox or a mail filter on the subject prefix.
It uses your automation allowance. Atlassian now measures automation usage in steps: every trigger, condition and action that runs counts as one. This rule is two steps per deleted work item. The Jira Free plan includes 150 steps a month per site, and Atlassian starts billing usage above the allowance on December 3, 2026. Check Automation → Usage to see where you stand.
Text only. Rich formatting in the description is flattened to plain text, which is fine for recovery but loses tables and images.
Who receives it matters. The email contains the full description of the deleted work item. Send it somewhere with the same access level as the project.

So is a rule enough?

For many small teams, yes, combined with two other basics: limit the permission to delete work items (called "Delete issues" in older permission schemes) to admins, and close or archive work items instead of deleting them.

If losing the comment thread or the worklogs on a ticket would hurt, a rule is not enough. Those have to be copied while the work item still exists, which is what restore apps on the Atlassian Marketplace do. They track work items continuously and recreate them after deletion, with a new key. My second post compares the current options.

A note on what I'm building

I'm working on Undelete for Jira, a Forge app that keeps deleted work items recoverable, comments and worklogs included, with tracking on for every project by default. It is not released yet. This test is part of figuring out what the free options already cover, so I don't build something you already have. If you want early access, or want to tell me what you lost the last time someone deleted a ticket, here is the early access list.

FAQ

Does the Work item deleted trigger work on the Jira Free plan?
Yes. I tested it on a Free site on October 16, 2026. Each run uses automation steps from the monthly allowance.

Can an automation rule restore a deleted work item?
No. It can only send what it can read at the moment of deletion. To get a work item back you have to recreate it, and it will get a new key.

Can the rule capture comments of a deleted work item?
Not in my test. Both the comment loop and {{issue.comments.last.body}} returned empty text.

Can I see who deleted a work item without an audit log?
Yes, if this rule was in place: {{initiator.displayName}} returned the name of the person who deleted it.

Does deleting a parent send emails for its subtasks?
Yes. Each subtask runs the rule separately, but its Parent field is empty in the email.

Sources

Atlassian Support: Automation smart values - issues
Atlassian Support: How is your automation usage calculated
Atlassian Support: Audit activities in Jira
Atlassian: JRACLOUD-36415, Have a Trash/Recycle Bin in Jira for work items
Test results: my own Jira Cloud Free site, team-managed project, October 16, 2026.

Using Restore Deleted Issues in Jira Cloud? What to Check Before Connect End of Support (January 31, 2027)

Aleksander — Mon, 12 Oct 2026 04:55:15 +0000

Short answer: If your Jira Cloud site relies on Restore Deleted Issues by Bloompeak Labs, check its future now rather than in January. As of October 12, 2026, its Marketplace listing shows version 1.0.5-AC, released on February 18, 2024, built on Atlassian Connect. Atlassian ends support for Connect on January 31, 2027. The app will not necessarily stop working that day, but you should ask the vendor about their plans and, if you decide to switch, run a replacement in parallel before you remove the old one. A restore app can only bring back work items deleted after it started tracking, so the order matters.

The rest of this post explains what Connect end of support means, what happens to the backups you already have, which alternatives exist today, and a step-by-step way to switch without a gap.

What "Connect end of support" means

Atlassian has two frameworks for Marketplace apps: the older Connect and the newer Forge. Since September 2025 new apps can only be listed on Forge, and since March 2026 Connect apps can no longer update their descriptors.

On January 31, 2027 Connect reaches end of support. Atlassian's own wording is worth reading in full: Connect "will not remain in a steady state after end of support. Breakages will increase and compatibility gaps will widen." After that date Atlassian will only address critical security issues.

In practice that means a Connect app may keep working for a while, then break after an unrelated platform change, with no fix coming. For most apps that is an inconvenience. For an app whose whole job is to be there on the day someone deletes the wrong ticket, it is a real risk, because you usually find out it stopped working at exactly that moment.

Is Restore Deleted Issues affected?

Here is what the public listing shows as of October 12, 2026:

Version: 1.0.5-AC for Jira Cloud. The "-AC" suffix is typical for Atlassian Connect builds.
Last release: February 18, 2024.
Installs: 937.
Trust signals: Cloud Fortified, but not "Runs on Atlassian", the badge Forge apps that keep data on Atlassian's infrastructure can earn.
Pricing: a $3 flat fee for up to 10 users, then $0.30 per user for 11 to 100 users.

I could not find a public announcement from Bloompeak Labs about a Forge version. That does not mean there isn't one planned. The simplest step is to ask them through their support channel, and to decide once you have an answer.

To check the rest of your apps, look at each Marketplace listing for the "Runs on Atlassian" badge and the version history, or ask your vendors directly which framework their Cloud app uses.

What happens to your existing backups

This is the part most teams miss when they switch.

Restore apps keep their own copy of your work items. When you move to a different app, that copy does not move with you. The new app starts tracking from the moment you install it and configure it. Anything deleted before that can only be restored by the old app.

So two practical rules:

Do not uninstall the old app the day you install the new one. Run both for a while, so recent deletions remain recoverable by one or the other.
Before you uninstall, restore or export anything you might still need. If the old app has an export option, use it. If it does not, restore the important items while it still works.

Alternatives available today

All three apps below are Forge apps with the "Runs on Atlassian" badge on their listings. The details come from each vendor's listing and documentation as of October 2026.

App	Installs	What it restores	Notes	Price for 11–100 users
Issue History for Jira (SaaSJet)	3,071	Fields and comments	A full change-history and audit app with a recycle bin. Does not restore time tracking or links; for attachments only the file name is kept	$150 a month at 100 users (Standard edition)
Restorify (Terano Apps)	about 170	Fields, comments, worklogs, links, subtasks	Tracking is off by default and must be enabled per project; snapshots kept 90 days by default	$0.45 per user
Who Deleted My Issues? (Sevidev)	about 235	Description, comments, worklogs, status	Last Cloud release June 2025	$0.28 per user

All three are free for up to 10 users. None of them documents restoring attachments: when a work item is deleted, its files are gone.

Prices and features change, so check the listings before you buy. If you only need a recycle bin, the dedicated apps are cheaper. If you also want a full history of field changes, Issue History covers both.

There is also a free option that is worth adding whatever you choose: Jira's audit log records deleted work items on all paid plans, and an automation rule with the "Work item deleted" trigger can send the key, summary and description to email or Slack at the moment of deletion. It does not restore anything, but it gives you an alert and a copy of the basics.

The restored work item gets a new key

One more thing to know before you pick an app. Restorify and Issue History both document that a restored work item is created again with a new key, and as far as I know Jira does not let any app reuse a deleted key. So PROJ-123 will not come back as PROJ-123.

Anything that pointed at the old key keeps pointing at it: links on Confluence pages, commit messages, links from other tools, bookmarks. When you compare apps, check whether yours records the old key on the restored item, so people can at least find it by searching for the old key.

Thanks to Mihai Perdum for raising this in the comments.

How to switch without a gap

Confirm what you have. In your Jira apps list, check whether Restore Deleted Issues is installed and who relies on it.
Ask the vendor about Forge. If a Forge version is coming soon, you may not need to switch at all.
Pick a replacement and install it now. Do not wait until January. The new app protects you only from deletions that happen after it is set up.
Turn tracking on for every project. Some apps track nothing until an admin enables projects one by one. Check that new projects are covered too.
Test it. Create a dummy work item with a comment and a worklog, link to it from a Confluence page, then delete it, restore it, and check what came back, including what happened to the Confluence link.
Run both apps in parallel for a few weeks, so either one can restore a recent deletion.
Restore or export anything you still need from the old app, then uninstall it.
Tighten the basics while you are at it. Limit the "Delete issues" permission to people who really need it, and add the automation rule above as a safety net.

FAQ

Will Restore Deleted Issues stop working on January 31, 2027?
Not necessarily on that date. Atlassian says Connect apps will degrade over time after end of support and may stop working without notice. Ask the vendor about their plans.

Can I move my existing deleted-issue backups to another app?
Not between different vendors' apps, as far as their documentation shows. Restore what you need from the old app before removing it.

Do I need an app at all?
If very few people can delete work items and you rarely lose any, the audit log plus an automation rule may be enough. If many people can delete, or you have lost work before, a restore app is cheap insurance.

Will a restored work item keep its original key?
No. It comes back with a new key, so links to the old key from Confluence and other tools stop working.

Does any app restore attachments?
None of the apps above documents it.

A note on what I'm building

I'm working on Undelete for Jira, a Forge app focused only on keeping deleted work items recoverable, with tracking on for every project by default. It is not released yet. If you are planning a move away from a Connect app and want to tell me what matters to you, or get early access, here is the early access list.

My earlier post covers every recovery option in more detail: How to Recover a Deleted Jira Issue in Jira Cloud (2026).

Sources

Atlassian: Getting Ready for Connect End of Support
Atlassian Developer Community: Connect End of Support extended to January 31, 2027
Atlassian Marketplace: Restore Deleted Issues
Atlassian Marketplace: Issue History for Jira
Atlassian Marketplace: Restorify
Atlassian Marketplace: Who Deleted My Issues?
SaaSJet documentation: Restore deleted Jira work items
Terano Apps: Restorify FAQ
Atlassian Support: Audit activities in Jira

How to Recover a Deleted Jira Issue in Jira Cloud (2026): What Works and What Doesn't

Aleksander — Tue, 06 Oct 2026 08:32:11 +0000

Short answer: Jira Cloud has no recycle bin for work items (issues). Once a work item is deleted, Atlassian Support cannot bring it back. You can recover it only from something that already existed before the deletion: a backup, a notification email, an automation rule, or a Marketplace app that was installed and tracking the project. If none of those were in place, the work item is gone and has to be recreated by hand.

The rest of this article covers how to find out what was deleted, each recovery route and its limits, and what to set up today so the next deletion is recoverable. Everything here is for Jira Cloud and was checked against Atlassian's documentation in October 2026.

Why there is no undo

Deleting a work item in Jira Cloud is a hard delete. The fields, description, comments, worklogs, attachments, links and subtasks are removed together.

Jira does have a trash, but only for whole projects (spaces): a deleted project sits in the trash for 60 days and can be restored. Individual work items do not go there.

The request for a work item recycle bin, JRACLOUD-36415, has been open since January 2014. As of October 2026 it has 706 votes and the status "Under Consideration". In 2020 Atlassian said it had no plans to support a trash for individual work items "for the foreseeable future".

Atlassian's own knowledge base article on the topic, updated in September 2026, is direct about it: "Atlassian backups can't restore individual deleted work items."

Step 1: Find out what was deleted, and by whom

Before trying to recover anything, confirm what happened.

Go to Settings → System → Audit log. You need the Administer Jira global permission.
Search for the event work item deleted, or type the work item key.

The audit log shows who deleted the item and when. It does not store the content, so you cannot restore from it.

Two limits to know about:

Deletion events have been in the audit log on all paid plans since February 2025. Sites where every Jira app is on the Free plan have no audit log.
Retention is configurable. If your site keeps audit events for a short period, an old deletion may already be gone from the log.

If someone ran a bulk delete, the audit log is also the fastest way to get the full list of affected keys.

Step 2: Recover the content

Every route below has the same condition: the source must have existed before the deletion.

Route	What must already exist	What you get back	Main limit
Notification emails or Slack messages	Watchers or a channel that received updates	Whatever the messages contain	Manual copy and paste
XML backup	A backup file taken before the deletion	Fields and comments, through a CSV export and import	Slow, new key, needs a second site
Atlassian Backup and Restore	The paid add-on, on Premium or Enterprise	A whole-site restore	Not for single work items; backups kept 30 days
Automation rule	A rule that fires on "Work item deleted"	The fields you chose to send	Only what the rule captured
Marketplace app	The app installed and tracking the project	Fields, comments, sometimes worklogs and links	Must be set up in advance

Rebuild from notifications

If the work item had watchers, their inboxes hold the creation email and every update. Search mail for the key. Slack or Teams channels connected to the project are another source. This is tedious, but for a single ticket it is often the quickest route.

Restore from an XML backup

This is the method in Atlassian's knowledge base:

Take a backup file that was created before the deletion.
Import it into a separate site. Importing a backup replaces the data on the site you import into, so do not import it into production.
Find the work item on that site and export it to CSV.
Import the CSV into your real site.

The imported work item gets a new key. Anything that referred to the old key, such as commits, links from other tools and bookmarks, will not point to it.

Atlassian Backup and Restore

Atlassian sells a Backup and Restore add-on for Jira, Jira Service Management and Confluence on Premium and Enterprise plans. Backups can be scheduled daily or weekly and are kept for 30 days. It is built for disaster recovery of a whole site or app. It does not restore one deleted work item into a live site.

An automation rule that captures deletions

Jira automation has a Work item deleted trigger. A rule with that trigger and a "Send email" or "Send Slack message" action can record the key, summary, description and other fields at the moment of deletion.

This does not restore anything by itself, but it gives you a copy of the content and an immediate alert. Test the rule on a throwaway ticket to see exactly which values arrive, and remember that it only helps for deletions that happen after you create it.

Marketplace apps

Several apps keep a copy of work items so they can be recreated after deletion. All of them work only for deletions that happen after the app is installed and configured. As of October 2026 the Atlassian Marketplace listings show:

Issue History for Jira (SaaSJet): a change-history and audit app that includes a recycle bin. Its documentation says it restores fields and comments, but not time tracking data or links, and that for attachments "only the name of the attachment is saved".
Restorify (Terano Apps): a dedicated restore app. Its documentation says it restores fields, comments, worklogs, links and subtasks, that tracking is off by default until an admin enables it per project, and that attachments are permanently lost.
Who Deleted My Issues? (Sevidev): logs deleted items and restores them, including comments and worklogs. The latest Cloud release on its listing is from June 2025.
Restore Deleted Issues (Bloompeak Labs): the most installed dedicated app. The latest release on its listing is from February 2024, and the listing does not carry the "Runs on Atlassian" badge. Atlassian ends support for the older Connect app framework on January 31, 2027, so check with the vendor about their plans before relying on it.

What you cannot get back

No route restores everything:

The original key. Jira does not reuse keys, so a restored work item always gets a new one.
Attachments. The files are deleted with the work item. None of the apps above documents restoring them.
The change history. A recreated work item starts a new history.

How to prevent the next one

Restrict the "Delete issues" permission. This is Atlassian's first recommendation. In most projects only admins need it. Check your permission schemes, and check team-managed projects separately because their roles are configured per project.
Close instead of delete. Use a status such as Canceled or Won't Do, or a resolution, for work that should disappear from boards.
Archive instead of delete. On Premium and Enterprise plans work items can be archived and restored later.
Add the automation rule above. It takes ten minutes and gives you an alert plus a copy of the main fields.
Schedule backups if losing a day of work across the site would be serious.
Decide whether you need an app. If your team deletes rarely and permissions are tight, the steps above may be enough. If many people can delete, or you have already lost work once, a restore app is cheap insurance.

What I'm building

I'm working on Undelete for Jira, a small Forge app that does one thing: keep deleted work items recoverable. It is not released yet. The plan for the first version:

tracking on for every project by default, with no per-project setup;
restore of fields, comments, worklogs, links and subtasks, one item or in bulk;
an alert when someone deletes many work items at once;
data stored on Atlassian's infrastructure.

Attachments are the hard part and will not be in the first version. If attachments are the thing you most need back, I would like to know, because it changes what I build first.

If you want early access, or just want to tell me what went wrong the last time someone deleted something: join the early access list.

FAQ

Can Atlassian Support restore a deleted Jira work item?
No. Atlassian's documentation states that its backups cannot restore individual deleted work items.

Does Jira Cloud have a recycle bin?
Only for whole projects, which stay in the trash for 60 days. There is no recycle bin for individual work items.

Will a restored work item keep its original key?
No. Any restore method creates a new work item with a new key.

Can I see who deleted a work item?
Yes, on paid plans, under Settings → System → Audit log, with the Administer Jira permission. Sites that are entirely on the Free plan have no audit log.

Can I recover deleted attachments?
Not through Jira and not through the restore apps listed above. Keep important files in a system that has its own version history.

I installed a restore app after the deletion. Will it find the work item?
No. These apps can only recover work items that were deleted after the app started tracking the project.

Sources

Atlassian Support: Restore deleted work items in Jira Cloud using local backup files
Atlassian Support: Audit activities in Jira
Atlassian Support: Overview of Atlassian Backup and Restore
Atlassian Support: Archive a work item
Atlassian: JRACLOUD-36415, Have a Trash/Recycle Bin in Jira for work items
Atlassian: JRACLOUD-59371, Provide an Audit Log for Deleted Issues
Atlassian: Getting Ready for Connect End of Support
SaaSJet documentation: Restore deleted Jira work items
Terano Apps: How to Recover Deleted Jira Issues