Jira Service Management (JSM) is a software platform developed by Atlassian, designed to help businesses manage their service desk operations efficiently. It provides tools for organizing, tracking, and resolving customer requests and issues, and it streamlines workflows to improve customer satisfaction.
At the core of JSM are queues, which help organize work smoothly. Queues in JSM are organized lists or channels where incoming requests, tasks, or tickets are grouped and managed, facilitating smooth workflow management for service desk teams. However, just like any other data in JSM, queues are at risk of unintentional deletions.
It is possible for someone on your team to accidentally delete a queue by mistake. Even if you have third-party Atlassian apps installed, the same thing could still happen if they’re not set up correctly. Sometimes, even Atlassian’s own internal operations or outages mess things up, and they’re only responsible for protecting the software from outside problems—not your data. Remember the big Atlassian outage in 2022? Many teams lost their data, showing just how fragile digital systems can be. Atlassian makes powerful tools like JSM, but they say, “Atlassian does not warrant that Customer’s use of the Products will be uninterrupted or error-free,” which means that they’re not responsible if your data gets lost.
Losing a queue means losing a particular view of your JSM issues, which, in turn, means you need to manually look through a bigger issues list to find the issue you’re looking for. This can create situations where issues go unresolved for long periods or hinder your team’s productivity. Hence, understanding how to restore deleted queues in JSM and prevent future mishaps becomes important.
In this article, you will learn how to avoid such scenarios and what you can do if you end up deleting a JSM queue. You will also learn how important and useful automated backup systems like Rewind can be in restoring order after such incidents.
How to Restore Deleted Queues in JSM
When you delete a queue in JSM, it’s gone for good. Atlassian doesn’t have a trash bin from which you can restore files. So if you accidentally delete a queue, you’ll see a message telling you it’s permanent:
While manually recreating a deleted queue might seem like a viable option, it has several significant drawbacks:
- Knowledge reliance: Recovery of your queue relies on your or your team’s memory of the queue’s settings. This approach can be unreliable, especially for complex filters or situations where team members may not recall the details precisely.
- Time consumption and error risk: Manual recreation can be a time-intensive process, especially for detailed filters. Additionally, you might introduce errors during the recreation process, which increases the potential for further complications.
That’s why it’s best to avoid deleting a queue unless you really have to. However, if you want to minimize the risk of losing your queues, a robust backup system can provide a dependable means of restoring them. Implementing a backup system allows you to plan ahead and set up backups for your JSM data, which you’ll learn about in the next section.
Regularly Back Up JSM Data
Just as you’d back up important files on your computer, you should also regularly back up your JSM setup. The most straightforward way to do this is using a dedicated backup platform like Rewind. Rewind works by automatically saving copies of your JSM data on a regular basis. Therefore, if you accidentally delete a queue, you can simply access the latest backup and restore it in your JSM instance.
To get Rewind, you can simply install it as an app in your Atlassian workspace. Once it’s set up, you can schedule it to back up your data automatically at certain times. On top of that, if you ever need an extra backup right away, you can trigger one manually using the Rewind interface.
It’s important to note that you must set up Rewind before you need to recover a deleted queue. If a queue is deleted before you set up Rewind, it’s gone.
How to Prevent Users from Accidentally Deleting Queues in JSM
Since it’s not possible to restore deleted queues in JSM, preventing accidental deletions should be your priority. The following sections outline a few ways you can prevent or at least reduce accidental deletions of JSM queues.
Permissions
One of the most important out-of-the-box measures you can implement to prevent accidental deletions of JSM queues is to restrict the number of people who can actually delete it. Only project admins are allowed to delete JSM queues; this means that you must carefully pick the project admins for your JSM projects.
Backups
Even with proper permissions in place, accidental queue deletion can still occur. To reduce this risk, implementing a regular backup solution is crucial. Tools like Rewind offer automated backups, eliminating the need for manual intervention and ensuring your Jira data is consistently protected.
Unlike traditional backups with potentially complex restoration processes, Rewind simplifies data recovery. With a single click, you can browse historical snapshots and pinpoint the exact version containing the deleted queue. This intuitive interface allows for swift restoration, minimizing downtime and ensuring users can resume working on the requests immediately.
The restored queue retains all its filters and other details, such as visible columns and favorite status. It would be very difficult to correctly replicate the exact queue configuration if you were trying to recreate manually.
User Education
As JSM queues are permanently removed upon deletion, accidental data deletion can have a significant impact on workflows and project timelines within JSM.
To mitigate this risk, user education across your team is necessary. The Atlassian Customer Agreement explicitly states that they hold no responsibility for data loss. The responsibility of data protection falls directly on your organization. Make sure that your team members are aware of this and the irreversible nature of deleting queues in JSM. Emphasize the importance of exercising caution when working with critical data, such as filters and columns.
Additionally, having a robust data backup strategy is very important. Regularly scheduled backups create a safety net, allowing for swift restoration in case of accidental deletion. Informing your team about the backup procedures helps build transparency and enables them to react confidently to potential mistakes.
Conclusion
While accidentally deleting a queue can be stressful, recovering deleted queues in JSM doesn’t have to be a permanent setback. The techniques outlined here, including minimal permissions, frequent backups with platforms like Rewind, and user training, can significantly reduce the risk of accidental deletion and keep your workflows on track.
However, unforeseen circumstances are always a possibility. Regular backups through services like Rewind, combined with established best practices, are your safety net. By building a culture of awareness, leveraging Jira’s built-in permissions, and setting up a robust backup strategy, you can ensure the safety of your critical data and navigate potential challenges with minimal disruption. This proactive approach minimizes downtime and empowers your team to focus on what matters most—delivering exceptional service.
