Requests created by customers to communicate suggestions, issues, and calls for help are the heartbeat of any service management team. They help guide you and ensure you offer the best possible user experience.
Imagine the chaos: A crucial customer request disappears from JIRA Service Management, leaving your team scrambling. Panic sets in, deadlines loom, and a hurried search for recovery begins. This situation is surprisingly common, with accidental deletions, system errors, or even malicious activities causing data to vanish abruptly. Misconfigurations in an app within your Atlassian workspace could also inadvertently delete a page in your Confluence workspace.
Interestingly, Atlassian relies on a shared responsibility model for security, meaning they manage application security, leaving data security to customers. Atlassian’s terms of service state that they don’t assure data preservation, and any breaches or errors on their part may lead to data loss. Beyond immediate disruptions, the ramifications of such data loss include wasted time, potential legal consequences, and added stress on the service management team—these are the hidden costs of a disappearing request.
This article explains how to restore requests through third-party apps and backup solutions like Rewind. It also explores how you can reduce the chances of accidental deletion, such as limited permissions and archiving instead of deleting.
Restoring Deleted Requests in JIRA Service Management
The accidental deletion of a request in JIRA Service Management can send shivers down any project manager’s spine. Unfortunately, the native functionality of JSM currently offers no built-in recovery mechanisms for lost requests. This means that once you hit the “delete” button, your requests are gone for good, and there’s practically no way to get them back.
To solve this problem, third-party tools like Bloompeak’s Restore Deleted Issues step in as potential saviors. These apps integrate with Jira Service Management and log information about deleted requests, allowing you to resurrect them with varying degrees of completeness.
While this may seem like the solution, there are a few trade-offs to consider:
- Cost: These tools often come with a price tag, adding an unforeseen expense to your JSM budget. For instance, Bloompeak’s offering is free for up to ten users, but it charges you 0.3 USD per user per month for each additional user after that.
- Lock-in: You become reliant on a third-party service, which can introduce potential vulnerabilities and points of failure.
- Limited functionality: For some tools, restoration capabilities may be limited, often failing to recover attachments or historical data.
If cost or dependence on third-party tools is a concern, you can try to manually recreate deleted requests. This involves scouring through emails, logs, and any lingering traces the request might have left behind. While this option avoids additional costs, it has its own set of drawbacks:
- Time: Recreating a request can be tedious and time-consuming, potentially taking hours depending on its complexity.
- Incomplete data: Manually reconstructing information can lead to errors and omissions, compromising data integrity.
- Limited possibilities: Manually recreating attachments or historical data can sometimes be impossible.
Instead of relying on reactive solutions like third-party tools or manual recreation, a proactive approach is far more effective. You should consider implementing an automated backup system like Rewind. You can set up Rewind to regularly capture snapshots of your Jira Service Management data (or do so manually when needed), allowing you to quickly restore lost requests (along with all associated metadata) to their original state.
Automated backups run seamlessly in the background and require minimal user intervention. They allow you to recover requests in their entirety, including comments, attachments, and historical data. Recovery is usually quick and simple, which minimizes disruptions and ensures smooth business continuity. Finally, it gives you peace of mind, knowing that your precious JSM data is always safe and available.
How to Prevent Users from Accidentally Deleting Requests in JIRA Service Management
Another proactive approach to avoiding such a situation is to prevent users from deleting requests in the first place. This section lists a few ways you can do that.
Archiving
Deleting requests might seem like the quickest way to declutter your JIRA Service Management, but it’s often an irreversible and potentially risky solution. This is why it is better to archive unneeded requests instead.
However, Jira Service Management does not offer an in-built archive feature. You need to use labels and filters to achieve this functionality. The logic is simple: create a special label like “Archived” and assign it to issues that are to be archived. You’ll also need to update your lists’ filters to exclude requests with this label.
Here’s how you can do it. Start by assigning an “archived” label for a request:
If it doesn’t exist in your project, it will be created automatically. Now, go to your project’s filters page (through the top navigation bar), and you’ll notice that the request is still visible:
You’ll have to adjust the search query of this filter to update which issues are shown. You can’t exclude queries via the basic search controls, so you’ll need to click on the Switch to JQL button:
Now, update the JQL query to something like project = DRAF AND labels not in (Archived) or labels is EMPTY ORDER BY Rank ASC.
This will exclude all requests with the label “Archived” but still include those without labels. Here’s what it would look like when you click the Search button:
You can see that all requests labeled “Archived” are now removed from the filter. Make sure to save this filter. To bring a request back, you simply remove the “Archived” label from it, and it will reappear in the filter.
Limiting Permissions
JIRA’s permission system lets you fine-tune who can delete requests. This granularity can prevent unauthorized individuals from making critical mistakes. Here’s how you can apply it effectively:
- Review default permissions: JIRA grants certain delete permissions by default. Analyze these permissions and adjust them according to your needs. For example, consider removing the “Delete Issue” permission from the “Service Desk Customer” role if you don’t want customers to inadvertently delete their requests.
- Create custom roles: Define specific roles with appropriate delete permissions for different user groups. This way, only project managers or designated IT personnel can handle deletions, while regular users can’t accidentally trigger irreversible actions.
- Leverage workflow transitions: Configure your workflow so that requests can only be deleted in specific states. For instance, allow deletion only in the draft state, but restrict it after the request has been assigned to an agent. This provides an extra layer of protection against accidental deletion when work has already begun.
Backups
Even after you set appropriate permissions, unforeseen circumstances can lead to deleted requests. In such cases, regular backups become your safety net. You can set Rewind to automatically take incremental backups of your JIRA instance at configurable intervals. No manual intervention is required, which ensures your data is constantly protected.
Unlike conventional backups that require lengthy restoration processes, Rewind lets you restore deleted requests with a single click. Simply browse the historical snapshots, pinpoint the desired version, and voila—your deleted request is instantly back in its original state.
Imagine the lost productivity if users have to recreate deleted requests, including filling forms, assigning priorities, and notifying stakeholders. Rewind’s instant restoration minimizes downtime and ensures users can resume working on the request immediately. This includes all the metadata and attachments with the request, meaning it feels as if the request was never deleted in the first place.
User Education
Educating your team about the consequences of accidental deletion and establishing best practices can also help significantly reduce risk. Make sure to clearly communicate the potential disruptions caused by accidental deletion. Highlight the time and effort needed to recover lost data and the potential impact on customer satisfaction.
Establish clear guidelines for handling sensitive actions like deleting requests. Let your team know if you have a solution like Rewind in place for their peace of mind in such situations.
Conclusion
While retrieving lost requests in JIRA Service Management can be a nerve-wracking experience, it doesn’t have to be a permanent disaster. By incorporating the restoration techniques outlined in this article, you can regain control and bring your deleted requests back to life. Remember, prevention is key. Granular permissions, frequent Rewind backups, and team education can significantly reduce the risk of accidental deletion and keep your workflow running smoothly.
However, unexpected situations can always arise. Don’t underestimate the power of regular backups through tools like Rewind and established best practices. By building a culture of awareness and utilizing JIRA’s built-in safeguards, you can ensure the resilience of your valuable data and navigate any challenges with minimal disruption.
