Relate new issue to other ones with same cause

[Tim H_]

I have a post function that automatically creates related issues. Example:

- Main issue is "Onboarding".

- Onboarding automatically creates issues like

- - Create account

- - Provide IT equipment

- - ...

My post function creates "is caused by" relations for each of those related tasks:

- Onboarding "causes" Create Account / Create Account "is caused by" Onboarding

- ...

Now, I want to relate those related tasks to each other:

- Create Account "relates to" "Provide IT equipment" and so on.

I wonder how to achieve that. I'm thinking about an automation rule, but I can't figure out how this works.

Trigger: Issue created

Condition: ? A JQL condition?

Action: ? A JQL action?

Any help is greatly appreciated!

[Jack Tucker]

Hi Tim, 

We had a similar issue, I think you could create an automation along the lines of: 

1. When an issue is created 
2. If request type = Onboarding (or summary includes "onboarding" depending on your setup) 
3. Create a branch for "All created issues" 
4. In the branch create new issue for each that you would like (issue type can be whatever you like) 
5. Then link to created issue 

[Tim H_]

Dear @Jack Tucker 

Thank you for this suggestion. In the past, I had a similar approach and created the sub tasks via automation. We then switched to the JMWE add-on in order to be able to create/clone the related tasks by using transitions.

This had several reasons:

• it seemed "cleaner" to only fire the code when it's really necessary (=post function) and not listen to each creation of a new task.
• we don't always have to perform every sub task. There are for instance onboarding cases without hardware involved.

Thus, the starting point for an automation would not be the parent task but the sub task itself. I probably need to look if there is a parent task and then do something. But I have no clue how this could be done...

[John Funk]

Hi Tim,

What I do is create an Epic for the Onboarding of each person. Then auto create the Tasks as children to the Epic. This is much cleaner for reporting and seeing progress. Doing everything by linkages gets very hairy. 

[Tim H_]

Dear @John Funk 

Thank you.

We actually had a solution like this in place. But there was a problem with commenting on sub-tasks. Those comments don‘t send e-mail notifications to the customers. So we had to change it to regular issues.

[John Funk]

You can create automation rules to send emails based on comments if needed. Or even copy comments up the chain. But with Epics and Tasks/Stories as children, not sure you need to go all the way down to Sub-tasks - that's a lot of details that will probably bog the process down. 

[Tim H_]

Dear @John Funk 

thank you. To be honest, I never worked with epics before, just with tasks and sub-tasks. Are epics different from a technical perspective? I always thought, it‘s just a task with a different name!?

[John Funk]

Yes, Epics are a different animal and have built-in hard connections between it and their children - just like there is between Tasks and Sub-tasks. But Epics sit at a level above Tasks. 

[Tim H_]

Dear @John Funk 

Thank you! And what's the role of stories in all of this? Is the hierarchy epics -> stories -> task -> sub task? If yes, should I use epics+stories, epics+tasks or stories+tasks? Is there a difference at all?

[John Funk]

Stories and Tasks sit at the same level. In this case with HR, I would just use Tasks and not use Stories. So I would use Epics > Tasks. 

[Tim H_]

Thank you, @John Funk 

I will now try to change to Onboarding and Offboarding issue types to epics. But I see one big problem: They have different workflows attached. Onboarding is different from Offboarding (both also have approval steps by the way). And I can only associate epics with one workflow. How would you solve this? Is it possible to create custom own epic types in Data Center?

[John Funk]

What I do is have the Epic to just be the name and it is basically To Do, In Progress, Done. Then you can have a Task level issue type called Onboarding and one called Offboarding. Those would/could have different workflows. 

You could add components for Onboarding and Offboarding if you like to attach to the Epics for reporting/tracking

[Tim H_]

Thank you, but unfortunately, I don't understand this, @John Funk 

If I implement Onboarding as a task and not as an epic, the elements of the onboarding process (=account creation etc.) would have to be sub tasks. Thus, Onboarding would have to be an epic in order to have the elements as tasks. Or am I missing something?

[John Funk]

Can you give me some exact examples of what the tasks and sub-tasks look like? 

[Tim H_]

Thanks, @John Funk , sure:

For the onboarding process

• Epic: Onboarding
• Tasks: Create Account, Provide Notebook, Grant Access to Drive X,... 

Those tasks can also be stand-alone request types. Users can use the customer portal to e.g. request an account to be created. Or to ask for a notebook, etc. 

The Onboarding process should bundle all these steps. Not every step, however, is necessary for every onboarding case. Sometimes, they need access to a certain drive, sometimes they don't. 

We implemented this by using JMWE post functions. We implemented an Onboarding issue type and associated it with an Onboarding workflow. This workflow has a status "In Progress" and several transitions from that status to itself like "Create account issue". 

Those transitions create an issue "Create Account" and copy the respective values from the parent ticket (Onboarding). Plus some other things like linking the parent issue to the child, because technically they are on the same hierarchy level as we don't use epics or sub-tasks.

I think that the issues like "Create Account" etc. should be on the task level. Of course, they are not epics. And if they are sub-tasks, users are not informed about comments and also I would not be able to use them for stand alone issues.

Thus, the Onboarding issue should either be on the same level (like it is now) and I have to create all the relations by using automation or other kinds of rules. Or Onboarding should be an epic. In this case, I would have to have more than one epic issue type. Because they Onboarding, Offboarding, ... should be treated differently.

And one last thing: Those complex types like Onboarding should be able to create other complex types like "Provide IT equipment". Because "Provide IT equipment" may contain several steps ("Provide notebook", "provide monitor", "provide docking station",...) as well.

I hope I was able to clarify what I want to achieve ;-) Again, thank you very much for helping me with this.

[John Funk]

So as far as structure, what you have is fine. Create an Epic with something like Onboarding for new hire Tim H. Add a component for Onboarding. Then create your Tasks underneath that for Create Account, Create Email, Setup Laptop, etc. 

I usually do that by having a JSM form where the requester has to fill out the form. That way you know which Tasks need to be created and which ones don't. So I have a base JSM project with Request Types like Onboarding, Offboarding, Access Request, etc. I also like to create issue types of the same name basically as the Request Types at the high level. You can expand as much as you want with HR tasks. 

Then I have a Jira Software project where the Epic and Tasks are actually created. I copy down the Component of Onboarding or Offboarding, etc. Then those with Jira licenses can work there and not need a JSM Agent license. All of the Epic and Task creations can be done with Automation. 

You can either create sub-tasks under the Provide IT Equipment task, or actually create individual Tasks - which is what i do, because sometimes it is different people anyway. And you get a better idea of actual progress by simply looking at the % complete of the Epic. 

How does all of that sound? 

[Tim H_]

Dear @John Funk 

thanks again. That sounds very interesting. But unfortunately, I don't really understand it fully ;-) I'll try to break it down:

• We only have Jira Service Management licences. No Jira Software.
• I don't want to work with sub tasks. It should either be task-level request types or epics.

Q1: How exactly would you create the tasks under "Provide IT equipment"?

You don't know beforehand if e.g. the user needs a docking station. Thus, I assume the agent has to create that task manually in the back end. In my current approach, this is done by using transitions and JMWE based post functions.

Thi would not be possible with epics as the epic issue type has to be associated with a generic workflow (because I only have one single epic issue type). Would you use the "Create" button in the backend? Or how would you create tasks under "Provide IT equipment? 

Q2: What is the role of components in all of this? I don't understand what you use them for. It sounds quite interesting, however.

[John Funk]

So, how many users do you have paid licenses for? And are they all helpdesk people? 

Next, I would design a form that asks all of those question up front - is a docking station needed? Yes/No. Pick a laptop from this list: A/B/C Pick a monitor from this list: A/B/C, etc. Then you just create the Tasks as needed. Provide IT equipment is too generic and I would not create a Task that says that. They should all be very specific - again, based on questions in the form that the requester fills out. 

No, I would not use the Create button - everything should be input on the form. 

Components are simply a way to categorize the work for reporting if needed. How many people did we Onboard in the last quarter? How many people did we offboard in the last year, etc. 

[Tim H_]

Right now, we have close to 100 persons using JSM, all of them have paid licences. Soon, we will have to upgrade to 250 agents (the next tier). Do you think there is an alternative way of working with JSM with fewer licences? The agents do not all have to communicate to the end users, but they have to have access to the issues and comment on them.

"Then you just create the tasks as needed" -> how?

-> So, you would not use the "Create" Button. I agree. But how should the tasks be created then? Automation rules based on the checkboxes the user activates? I'd prefer transitions, but as I stated above, I can't see how I can do this with generic epic workflows.

[John Funk]

Maybe it would be better to just have a conversation if you are up for that. Here is my LinkedIn account if you want to connect. 

https://www.linkedin.com/in/john-funk-92261a38/