Guest Contributor: Mary Ramirez
As Atlassian consultants, many organizations come to us for best practices and recommendations. One use case we often see is leveraging Jira to onboard and offboard users. Typically, this is led by the Human Resources team and includes other departments like Information Technology and Finance. In my experience, I see many organizations fail to include Jira in their offboarding process. When users are onboarded into Jira, they typically create many artifacts and become owners of dashboards, projects, and spaces. Once they leave, teams aren't able to make edits to configurations that were previously owned by an employee that is no longer with the company.
Before we start offboarding users, let's review a few things:
Rule of Thumb...Never Delete Users!
Users should not be deleted from Jira or Confluence. When a user is deleted from Jira, any content they previously posted will also be removed, including comments, issues, or pages. We recommend disabling users in Jira in order to maintain the data.
Check It (Artifacts) Before You Wreck It
Make sure you do a thorough check of the following artifacts before you begin the offboarding process.
- Issues - Are there any open issues that are assigned to the user who is about to be offboarded?
- Filters - Filters drive dashboards and reporting, and are generally owned by one person. Make sure that that person is NOT the one who is leaving your organization.
- Dashboards - Ensure that somebody who is on the current team is the dashboard owner.
- Scrum or Kanban Boards - If needed, transition ownership of these boards to a current member of the team.
- Group Membership - Ensure that the soon-to-be offboarded person is not in a group of one.
- Project Lead - There is only one lead per project, so you'll want to be certain that it is somebody who is still employed at your organization.
- Project Administrator - Check that somebody else on the current team is also a project administrator.
- Confluence Space Owner - Hopefully, you're using Groups! If not, it's time to start 😀.
- Restricted Pages - Space admins can see restricted pages. Are there any of these pages that are assigned to the employee who is being offboarded? If so, they should be transferred to new owners.
Next Step...Set Up the Offboarding Process
Here's an easy 3-step process to use when you offboard users in Jira:
- Depending on where the offboarding process begins, there should be a parent ticket created. The parent ticket should include details like the user's name, their termination date, and their manager's name.
- Once the parent ticket is created, a linked sub-task should be created for departments or products that should be included in the offboarding process. In this case, one should be created for the Jira team to use.
- The Jira team should check the artifacts listed above for the user being terminated. In the Jira ticket, any artifacts that are transferred onto another user or removed should be annotated.
Leverage Automation for Jira
I recommend using Automation for Jira for your offboarding process. Trigger an automation of the sub-task issues from the parent ticket for all of the teams involved. It will also do the manual work of notifying other teams, either through email or Slack once the tickets are closed.
So What's the Benefit of All of This?
Regularly offboarding users helps Jira Admins identify unused artifacts that can be deleted. Instead of waiting to identify and clean unused artifacts on a quarterly basis, Jira admins can do so throughout the year. This will reduce the amount of hours Jira Admins take to clean the Jira instance and allow them to work on other operational tasks. When users are deactivated, they no longer use a Jira license. This helps organizations save money in the long run.