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.
Top comments (0)