When we talk about employee lifecycle management, onboarding usually gets most of the attention. But offboarding is equally important.
When an employee leaves an organization, there are several things that need to happen. The manager needs to complete the handover, IT needs to collect company assets and remove access, HR needs to complete the exit formalities, and Finance may need to complete the final settlement.
If all of this is managed through emails, spreadsheets, and manual follow-ups, it can become difficult to keep track of everything.
So, I wanted to bring the complete process into Jira Service Management and make it easier to manage from one place.
In this article, I'll walk through how I approached the employee offboarding process and some of the JSM features I used along the way.
What I Wanted to Achieve
My main goal was to create a simple process where everyone involved in the employee's exit knows:
Instead of having one person coordinate everything manually, I wanted JSM to handle as much of the routing and follow-up as possible.
The overall process looks like:
Resignation → Approval → Clearance → Finance → Exit Documents → Closure
The process can also change depending on the type of exit and the information provided in the request.
Starting the Offboarding Request
For a normal resignation, the employee can raise the request through the JSM portal.
I created a form to collect the basic information required to start the process, such as:
Once the request is submitted, the main offboarding ticket is created and sent to the reporting manager for review.
This gives us a proper starting point instead of beginning the process with an email or a message.
Handling Resignation and Termination Differently
One thing I wanted to keep separate was voluntary resignation and termination.
For a resignation, the employee can start the process themselves.
For termination, the request is created by HR. Employees don't see a termination option on the portal.
This is important because termination requests contain sensitive information and should only be accessible to the appropriate HR users.
Manager Review
After the employee submits the resignation, the request goes to the reporting manager.
The manager can review the resignation, confirm the proposed last working day, and start planning the knowledge transfer.
If an employee requests an early release, the manager can also recommend whether a notice-period waiver or recovery is required.
This is where I started adding some conditional logic to the process.
Adding Conditional HOD Approval
I didn't want every resignation to go through the same number of approvals.
For example, if an employee is following the normal notice period, there may not be a reason to involve the HOD.
But if there is:
then the request can be routed to the HOD for additional approval.
If none of these conditions apply, the request can move directly to HR.
This keeps the process simple for standard cases while still handling exceptions properly.
HR Final Review
Once the required approvals are completed, HR performs the final review.
HR checks the resignation information, notice period, and last working day before moving the request into the actual offboarding process.
This gives HR a final checkpoint before the departmental clearance activities begin.
Handling the Last Working Day
The last working day may sound like a small detail, but it can create problems if it isn't handled correctly.
For example, the process includes rules for cases where the calculated last working day falls on a Saturday or a public holiday.
In those situations, the previous working day is used.
The notice period can also be based on the organization's standard policy, such as 30 or 60 days, or whatever is defined in the employee's appointment letter.
Automatically Creating Clearance Tasks
This is one of the areas where JSM automation can really help.
After HR gives the final approval, the system can automatically create the required clearance tasks.
In my design, the main clearance activities are:
-
Manager Clearance
-
IT Asset Clearance
-
HR Clearance
-
Finance Settlement
These tasks are connected to the main offboarding request, so everything remains linked together.
This also makes ownership much clearer because each team gets its own task.
Manager Clearance and Knowledge Transfer
The manager's work doesn't finish with approving the resignation.
Before the employee leaves, the manager needs to make sure that the work has been properly handed over.
The manager can confirm things like:
There is also a place for the manager to add comments.
This helps make knowledge transfer a formal part of the offboarding process rather than something that is handled informally.
IT Clearance and Asset Recovery
IT clearance is another important part of the process.
When an employee leaves, the IT team needs to recover company assets and disable the required system access.
The assets can include:
-
Laptop
-
Monitor
-
Keyboard
-
Mouse
-
Headphones
-
Laptop Bag
The IT clearance task can track whether each item has been returned and whether any asset recovery is still required.
This is much easier than maintaining a separate spreadsheet just to track who has returned what.
It also gives us a clear record that can be referred to later if there is any question about an asset.
HR Clearance
HR has its own set of activities to complete.
The HR clearance includes things like:
-
Collecting the employee ID card
-
Disabling biometric access
-
Completing the exit interview
-
Verifying the required documentation
The HR task can include fields such as:
-
ID Card Returned
-
Access Disabled
-
Exit Interview Completed
-
HR Comments
Once these activities are completed, HR has a clear record of what was done.
Finance and Full & Final Settlement
Once the clearance activities are completed, Finance can work on the Full & Final Settlement.
Depending on the employee's situation, Finance may need to consider:
-
Pending salary
-
Leave balance
-
Notice-period recovery
-
Asset recovery
-
Final settlement amount
The settlement task captures the relevant financial information and its current status.
This is also where information about missing assets or notice-period recovery can become important.
Adding an Exit Interview
I also wanted the process to capture employee feedback before the exit.
For this, an Exit Interview Form can be shared with the employee.
The form can ask about:
HR can review the responses and discuss anything that needs further attention.
I think this is useful because offboarding shouldn't only be about completing checklists. It can also be an opportunity to understand what employees experienced during their time with the organization.
Using Automation to Connect Everything
Automation is what helps bring the different parts of the process together.
Some of the automation actions include:
-
Assigning the request to the reporting manager
-
Sending the request to HOD when required
-
Moving the request to HR after approval
-
Creating clearance tasks automatically
-
Notifying teams when their tasks are ready
-
Moving the process to Finance after clearance
-
Notifying HR after settlement
-
Starting the exit-document stage
The idea isn't to automate every possible action.
It's mainly about removing repetitive manual work and making sure that the right person gets the right task at the right time.
Tracking Employee Assets
If Assets is being used in JSM, the offboarding process can become even more useful.
IT can check the assets assigned to an employee and update their return status as part of the clearance process.
This makes it easier to identify missing equipment and, when required, pass the recovery information to Finance.
So the asset information becomes part of the employee's exit record instead of being maintained separately.
Adding SLAs
I also wanted to make sure the process could be measured.
Some example SLAs are:
| Activity |
SLA |
|---|
| Manager Approval |
2 days |
| HR Approval |
2 days |
| Department Clearance |
5 days |
| Finance Settlement |
5 days |
These SLAs can help identify where the process is taking longer than expected.
Queues for Different Teams
Different teams don't need to see every offboarding request.
So, queues can be created based on responsibility.
For example:
-
HR Offboarding Requests
-
Manager Approvals
-
IT Clearance Tasks
-
Finance Settlement Tasks
This makes it easier for each team to focus on the work that belongs to them.
Dashboard Visibility
For HR and leadership, dashboards can provide a quick overview of the current situation.
Some useful metrics could include:
-
Active Offboarding Requests
-
Pending Manager Approvals
-
Pending Clearance Tasks
-
Completed Offboarding Cases
-
Pending Finance Settlements
This provides a simple way to identify bottlenecks without opening individual tickets.
Completing the Offboarding Process
The employee's exit isn't considered complete just because the last working day has passed.
There are still some final activities that need to be completed.
The process includes issuing:
Relieving Letter – after the required clearance activities are completed.
Experience Letter – after the Full & Final Settlement is completed.
Once the required activities are finished, the offboarding request can be closed.
Final Workflow
So, if I put the complete process into one simple flow, it looks like this:
Employee Resignation → Manager Review → HOD Approval (if required) → HR Approval → Clearance Tasks → Finance Settlement → Exit Documents → Closure
Behind this simple flow, JSM handles the forms, approvals, automation, tasks, notifications, SLAs, and reporting.
What I Like About This Approach
For me, the biggest advantage is visibility.
Instead of HR having to chase different people for updates, the status of the process can be seen directly in JSM.
The manager knows what needs to be completed.
IT knows which assets need to be recovered and which clearance activities are pending.
Finance knows when the request is ready for settlement.
And HR has a complete view of the employee's exit.
The final completion criteria are straightforward: departmental clearances must be completed, Finance must finish the Full & Final Settlement, the required exit documents must be issued, and the offboarding request must be closed.
Final Thoughts
Employee offboarding involves much more than simply marking an employee as inactive.
There are approvals, handovers, assets, access, documentation, finance, and employee feedback involved in the process.
By bringing these activities into Jira Service Management, we can create a more organized and transparent way of managing employee exits.
What I found most useful is that JSM allows us to connect all these activities together instead of managing them separately.
Have you implemented an employee offboarding process in Jira Service Management? What challenges did you face with approvals, asset recovery, or access removal? I'd be interested to hear how others are handling it.
