Question: For those of you running onboarding/off-boarding requests through JSM, do you use the Task and Sub-task work types, or have you created custom ones for onboarding and off-boarding? Background: We're setting up JSM for Human Resources project and the first workflows we want to deploy are for employee onboarding and off-boarding. There seems to be good support for this use case out of the box with templates already available, but I'm wondering how much (or often) others teams feel the need to update their work types in order to better identify onboarding/off-boarding in their queues. I could see doing one of the following and I'm wondering if any of you have opinions about it: * Create a custom Onboarding / Off-boarding work types at level 0 and use the existing Sub-tasks at level -1. * Use Task / Sub-task and create filters that match on tags "onboarding"/"off-boarding" or those words in titles. Option #2 keeps the ontology cleaner but option #1 feels more intuitive and less prone to something like a missed tag. However, it seems to also require another custom work type "IT Request" at Level 0 which is how we want to structure the IT side of the workflow. This complicates the ontology even more which isn't necessarily a bad thing, but simple is better than complex, IMHO. The main reason we're structuring the IT side of the process as a Level 0 task and not a Sub-task is that we need to set up an integration with our external IT provider who uses another ticketing system entirely but we need to keep our own due to audit traceability around things like SOC 2 and ISO. Lots to unpack here! But I would appreciate any thoughts or lessons learned you might have. Thanks!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Work types for employee onboarding and off-boarding

Scott Stevson

Question:

For those of you running onboarding/off-boarding requests through JSM, do you use the Task and Sub-task work types, or have you created custom ones for onboarding and off-boarding?

Background:

We're setting up JSM for Human Resources project and the first workflows we want to deploy are for employee onboarding and off-boarding. There seems to be good support for this use case out of the box with templates already available, but I'm wondering how much (or often) others teams feel the need to update their work types in order to better identify onboarding/off-boarding in their queues. I could see doing one of the following and I'm wondering if any of you have opinions about it:

Create a custom Onboarding / Off-boarding work types at level 0 and use the existing Sub-tasks at level -1.
Use Task / Sub-task and create filters that match on tags "onboarding"/"off-boarding" or those words in titles.

Option #2 keeps the ontology cleaner but option #1 feels more intuitive and less prone to something like a missed tag. However, it seems to also require another custom work type "IT Request" at Level 0 which is how we want to structure the IT side of the workflow. This complicates the ontology even more which isn't necessarily a bad thing, but simple is better than complex, IMHO.

The main reason we're structuring the IT side of the process as a Level 0 task and not a Sub-task is that we need to set up an integration with our external IT provider who uses another ticketing system entirely but we need to keep our own due to audit traceability around things like SOC 2 and ISO.

Lots to unpack here! But I would appreciate any thoughts or lessons learned you might have. Thanks!

Accepted answers

Christopher Yen

Hi @Scott Stevson welcome to the community!

We set up onboarding and offboarding and took a different approach for each.

For onboarding we have a somewhat sequential process where a single work item is aligned with the onboarding employee. As it transitions through the workflow we add additional checklist items and move it through different team queues which also generates notifications to the employee such as equipment tracking # and ultimately closes with a onboarded employee. So essentially 1 work item that flows through different teams using checklists instead of tasks

For offboarding we have multiple teams working at the same time such as hardware teams collecting equipment back, and software teams reclaiming licenses so we went with generating sub tasks assigned to each team with a parent work item that waits for sub tasks to resolve before auto resolving via automation. For us it really just depends on what the teams process is and we just tried to match the JSM workflow and work item structure to what ever is easiest for the teams to understand and work on.

Matteo Vecchiato

Hi @Scott Stevson

Welcome to Atlassian community and thank you for your question.

There isn't a fixed rule for this, it should be considered a specific work type if:

There is a different workflow/process than standard tasks
The information collected is very different than standard tasks

For reporting purpose you can differentiate by request type, it's not a best way differentiate by summary content.

The sub-tasks in my opinion should be used if the the onboarding/offboarding require to be spotted in several actions, done by differents agent or different phase. Other ways, it cause more management not required.

I hope it helps

Regards

Viktoriia Golovtseva (TitanApps)

Hey @Scott Stevson

Welcome to the community. We at TitanApps faced a similar challenge and opted for standard Task/Sub-task types combined with our tools Smart Templates and Smart Checklist to manage onboarding and offboarding in our team.

Templates help us standardize requests for different roles or locations, and checklists make it easy to break down each task into specific steps (e.g., IT setup, account access, equipment). This way, we keep the issue types simple while making workflows clear, auditable, and consistent.

If your external IT provider needs Level 0 issues, you can still use templates and checklists to streamline everything while maintaining traceability. You can check our use cases here: onboarding and offboarding

Anderson Ryan_w5azhn

In our setup, we customized the workflow slightly to make onboarding and off-boarding easier to track. We created distinct work types to clearly separate the two processes, which avoids confusion with tags and ensures better reporting. This also helps when working with external IT providers since each flow is traceable. For teams looking to streamline processes further, exploring services from the can also be useful, especially when planning resource allocation and cost estimation for large-scale onboarding/off-boarding initiatives. Click here: https://www.unityestimating.com/top-estimation-companies-in-the-usa/

All comments

Christopher Yen

Hi @Scott Stevson welcome to the community!

We set up onboarding and offboarding and took a different approach for each.

Scott Stevson

Hi @Christopher Yen thanks for the warm welcome!

This is great context, so thanks. I do like the single ticket approach for simplicity but I'm not sure I'll be able to use it since IT is a contractor and we ideally want to keep the hardware and desk assignment details segregated from the more personal HR ones. The issue here is employee PII other than first_name/last_name going to an external ticketing system we don't have visibility into.

Can you point me to the resources you used to create the workflow with the single work item? I'd like to better understand how you add the additional checklist items.

Thanks!

Mikael Sandberg

Like @Christopher Yen I used specific work items for onboarding and off-boarding. We started off by adding sub-tasks for external teams, but then changed it so we created tasks in each team's project, that way we didn't have to add/remove external users in the HR project. And I know one team used checklists as well, so they had one ticket linked to the onboarding in the HR project and then used the checklist to complete there work.

Matteo Vecchiato

Hi @Scott Stevson

Welcome to Atlassian community and thank you for your question.

There isn't a fixed rule for this, it should be considered a specific work type if:

There is a different workflow/process than standard tasks
The information collected is very different than standard tasks

For reporting purpose you can differentiate by request type, it's not a best way differentiate by summary content.

I hope it helps

Regards

Scott Stevson

Great, thanks. I'm testing the custom types in a sandbox project and they seem to be the way to go so far. I also like the thought of not getting too deep in the weeds with subtasks, so I'll test that as well.

Thank you for the input!

Scott Stevson

It does. Thank you, @Matteo Vecchiato !

Viktoriia Golovtseva (TitanApps)

Hey @Scott Stevson

Scott Stevson

I'll check it out. Thanks, @Viktoriia Golovtseva _TitanApps_ !

Anderson Ryan_w5azhn

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management