Have you ever experienced frustrating information delay between teams when it comes to on and offboarding of employees or contractors?
Effective collaboration between managers, IT Operations and People Operations, aka HR, is key for safe and smooth People Operation processes. In this article we explore the HR templates in Jira Service Management and show how we can improve that even further with Asset capabilities in Jira Service Management Premium.
Typical people requests are onboarding and offboarding employees or contractors. This work tends to be cross functional in its character as different teams are involved. In the best of all worlds the work is:
enjoyable for the employee
easy for the manager to initiate and deal with
friction free for People operations
timely for IT Operations.
Especially IT Operations have too many times needed to scramble and find hardware quickly and grant accesses in a hurry as someone forgot to tell IT that "It's Ms Smith's first day today."
In the process from knowing that an employee will start to them being fully up to speed with the correct hardware and software you might be facing some delays. If you’re not running a stock of laptops and mobile phones or if your workforce is distributed you will be facing some delivery delays. Information delays however, can be remedied!
Offboarding can lead to similar nightmares. Who took care of that mobile phone or laptop? How long has the former employee had access to business information after leaving the company?
Not having control over these people operation processes leads to a number or risks from information security breaches to not have the correct accesses in time to do the job.
Having an easy way to report that an employee is leaving the company, clearly defined and predictable actions that needs to be taken by what team will save time and be a much more enjoyable process for all parties involved. Here is how to do it!
Since people operations are dealing with humans much can happen that there isn’t a written policy or guide for. However on & offboarding is not one of them. We know what needs to be done and by whom. It should be a guided process that can open for some flexibility depending on situation.
Jira Service Management comes shipped with Project templates for HR to help getting you started. Choosing the larger template “HR service management” gives you the seven most common requests and you can of course add more requests or change the forms to tailor it to your needs.
Let’s have a look at the offboarding request template. A very good start, it catches the most important pieces of information that People Operations need to be able to organise an offboarding.
The workflow allows the people operation agent to choose an approver to ensure the offboarding is valid before proceeding with reviewing information and completing the work.
Much of the information requested in the offboarding form is likely to be known already. Most companies has a user directory in which users, accounts, managers and even application licenses by user are stored. Popular directories are Microsoft Entra ID (formerly known as Azure AD), Okta and Google workspace.
With Jira Service Management Premium you will get asset management capabilities where you can store any kind of object and define relations between them. Typical objects are the users, groups, application licenses and locations.
It’s a risk to duplicate important data in more than one application. Using Pio´s importers to sync that data in Assets, will mean that you don’t need to input and maintain the data manually. You sync the data on the interval of your choice from the source. It takes only 5 minutes to set up the importers. As a part of the setup the app will create a mirrored object schema automatically based on the data model of the source.
After initial install you need connect your user objects from the directory with their Jira user accounts. Follow this guide you connect them automatically.
When Assets and Pio sync is in place we can simplify the offboarding request form to only contain:
a user picker
resignment date
last working date
like this:
The rest we can automatically find in the directory, via Assets. Here is how
Text fields open for spelling errors. Replace this with an asset field fetching and displaying the users synced from AD.
Limit the Asset field (with filter issue scope) so the manager creating the request only can choose their employees. Like this:
"Manager"."Jira User" == ${reporter}
Since these attributes, amongst a lot of other user attributes, are known in the AD we can fetch and display them instead of forcing the user to input the data again in the form. Asset fields can be expanded to display chosen attributes
Associated software licenses is a valuable piece of information in offboarding.
If you want the manager to initiate the offboarding you may conclude that the approval step in the workflow is redundant and remove that step from the workflow altogether.
If you foresee that you will have other users, like assistants or people operation to initiate the request, then using the project automations to set the approver upon request creation might be a good time saver
Using this smart value you can set the approver field with the manager of the user you picked :
{{issue.customfield_XXXXX.Manager.Jira.accountId}}
(replace the XXXXX with the custom field ID for your Peoples-asset field)
To ensure standardization and quality in the process of offboarding employees, use automations to generate these tasks. Examples of tasks might be:
Employee filling out an exit survey
Manager arranging a farewell meetup
IT collecting the laptop, phone, monitor, sim card
Manager collecting the building entrance card
IT disabling the AD account, and ensuring all licenses are disabled
In its simplest form use the "Create subtask" action in the automation and give each subtask a summary.
To add more value you can copy fields from the parent issue to the subtasks. As an example the exit survey might need to have a due date set based on the last working date with an offset of 14 business days.
Why not add operating procedure texts or links to templates and how to’s stored in confluence?
Some tasks belong to teams outside or People Operations. IT Operations will need to disable accounts and retrieve hardware.
Expand the above automation to create issues in other projects, and copy just enough information to them
It is a good practice to involve the manager as a request participants on the related tasks to keep them in the loop. Adding a link back to the parent ticket so People Operations can oversee the total progress.
If you have a distributed ownership of revoking application licenses manually, ie applications where your AD account is not provisioning the licenses, you can store those licenses in the Object schema. The license should have an attribute on what team have the responsibility to disable the license. Our automation can then be expanded to create tasks to those teams if an employee in the object schema is connected to such a license.
Your People Operations portal should generally be open for all the employees in the organisation, but some requests, like onboarding and offboarding, should be privy to managers.
If you synced your AD to Jira you can apply AD groups to the request permissions. Ensure you have a manager-group in your AD.
To build the above I spent less than an hour using:
The result is saving time, increase quality of the practice plus minimise risk and frustration in this area of work.
Happy collaborating!
Lisa
Lisa Forstberg
Atlassian Expert Consultant
[LN Forstberg AB]
Gothenburg, Sweden
79 accepted answers
3 comments