What happens if you delete something in Jira Cloud?

When we start working with Jira, one of the most recurrent questions from new users is: what happens if I delete something? Can I recover it?  Is there an undo or go back option?

Keeping reading, and you will find out what happens in each case, depending on the Jira item you delete, whether you can recover it or not and how to proceed.

We are going to separate it into two big groups, on the one hand the internal users of the tool, also known as Agents or Servicedesk Users, and on the other hand, the Administrators.

For the users of a project…

If in a ticket or task we delete the value of a field or replace it with another, we will find the previous value in its history, so technically we would not lose the value. We could recover it at any time.

This would not be the case for attachments and text comments, with or without attachments, that we add to the ticket. If these are deleted, they cannot be recovered. They would have to be uploaded again.

We cannot retrieve the worklogs either. If someone deletes the log hours record in an incident or request, we will lose that value. Actually, we could recover the populated value because it will appear in the history, but we would not be able to recover the time when the work was done, nor the comment of the work.

If we delete the ticket, we won’t be able to recover it unless we use an external feature such as ‘Restore Deleted Issues’, which must have been installed in the instance before the ticket was deleted. We cannot use it afterwards if we have already deleted the task.

However, the person executing any of these actions will remain in the ticket history, so we will know who was responsible for the deletion.

The only case that does not leave a trace in the history is the deletion of a ticket or task. It is possible that Atlassian will add this functionality, as many users have requested it.

For this reason, the ability to delete comments (your own and others), time tracking (your own and others), attachments (your own and others) or tasks, should be reserved for administrators or a limited group of users because, as you can see, there is a certain risk involved.

Another thing we cannot recover if we delete them is filters. Once deleted, they cannot be recovered natively.

The same does not happen with dashboards. In this case, if we delete them, we will have 60 days to recover them.

To recover a dashboard that was sent to the trash, we will have to access the System menu, and in it look for the option Dashboards. Click on Show dashboards moved to the trash to be able to view them. Once located, click on the three dots on the right and then click on Restore.

For Jira administrators

In this case there are more options available, which only administrators can execute. For example:

Forms in Jira Service Management. If we want to delete a Form that we use in a Jira Service Management project, the tool will let us do it but indicating the type of request to which it is connected (if it is connected) and therefore what it could mean. This option can also be done by project administrators.

In addition, it would confirm that the following requests will lack this form but that the existing ones will not lose it.

If we delete a component and it has been used in a ticket, it will ask us if we really want to delete it, and lose it definitively (unrecoverable) or if we want to attach another component to all the tickets that have that component, which is going to be deleted.

If we delete a version, it will also be unrecoverable.

Forms, components and versions can also be deleted by project administrators.

Using Jira Software, we will use boards (Kanban or scrum). If these were to be deleted, we would not be able to recover them, although this would not affect the issues on the dashboard or complete or delete any active sprint.

Another thing we should not delete, as long as they are listed as assignee, reporter, etc., are the Agents. That is, people who have worked within a project, who have opened tickets, managed tickets, or are in some user selector type field.

If we delete them and then search for them using a jql, the name will not appear and we will have to search for the issues by user id, which can be quite a complicated task.

Issues: the types of incidents can be deleted as long as we don’t have incidents with that type assigned, otherwise we will have to move it to another different type that does exist.

Schemes of types of incidents: we can delete them and they will not be recoverable, but the tool will use the default scheme in the project where the scheme of types of incidents that we are going to delete was connected. So there will always be a schema associated to the project.

Workflows: we can delete them and they will be unrecoverable, but they cannot be active, that is, they cannot be in any workflow schema if it is also active.

Workflow schemes: the same as workflows, they can only be deleted (and will be unrecoverable) if they are not active.

Screens: can be deleted and will be unrecoverable, as long as they are not connected to a Screen Schema or apply to any transition of a workflow that is in production.

Screen layouts/Screen schemes by type of incident: we can delete them and they will be unrecoverable, but to do so they do not have to be connected to any project.

Custom fields: if we have a field and we delete it, the field and the information it contains in all issues where it has a value will be stored in the trash for 60 days.

After these days, we will lose the field and the data stored in it pertaining to each incident.

If we wanted to recover the field, we would click on the cogwheel and then click on Incidents. Then we would look for the Custom Fields menu.

Once in the Custom Fields menu, click on the In Bin tab. Then click on the three ellipses on the right, and then click on Restore field, in the field you want to restore.

States: we can delete them and they will be unrecoverable, but we can only delete them if we previously deleted them from the workflows that are in production.

Resolutions: we can delete them and they will be unrecoverable, but if there are incidents in which we are using the resolution we are going to delete, the tool will force us to select a new resolution.

Priorities: we can delete them and they will be unrecoverable, but if there are incidents with that priority being used, before deleting them the tool will force us to select a priority for those incidents that are going to be ‘orphaned’.

Issue security scheme: we can delete it and it will not be recoverable, but to do so the scheme does not have to be connected to any project.

Notification schemas: we can delete it and it will not be recoverable, but to do so the schema does not have to be connected to any project.

Permission schemes: we can delete it, but it will not be recoverable. If it is connected to a project, it will be assigned the default permission scheme.

Another option that we will not be able to recover if we delete it, is that of the automations, so we will have to be very sure before deleting.

And finally, the projects. If we delete them, they will be stored in the trash for 60 days. After those days, they will be permanently deleted.

There is a different way for users not to be able to see a certain project: archiving it.

To retrieve it or remove it from the archive, first we have to go to the Projects menu. To get there, click on the cogwheel in the top right-hand corner of the screen and then click on Projects.

If we had previously deleted it and wanted to recover it, we would go to the Trash menu, look for the project to restore, click on the three dots on the right and then click on Restore.

In case we have previously archived it and we want to recover it, we will click on Archive, then we will look for the project to recover, we will click on the three points on the right and then on Restore.

And after this, what would be the recommendation before deleting something?

First of all, the recommendation, as a general rule, would be that Jira agents or users should not have permissions to delete what we discussed above. This job should be reserved for instance administrators or project administrators, to avoid possible errors.

Whenever the administrators are going to delete an issue or several issues, if it is going to be done through a bulk action, they must make sure that those issues are not going to be needed anymore, because once they are deleted, they are lost forever. Better always two revisions than one.

As an option, we could create a project exactly like the project where the issues we want to delete are and use it as a backup. In such a way that we can go back to those issues in case we need to. Permissions could be removed from all users, so that it would simply be a consultation project for administrators and a place to go if we need to retrieve an issue. After a reasonable period of time, it could be permanently deleted.

And as a recommendation, both for Agents and users as well as for Jira Administrators, common sense: if something is unrecoverable we have to make sure, before executing the change, of the impact it is going to have on our instance.

Adolfo Rodríguez  31 de enero de 2023