Why don't we have "create sub-task"?

[Jamien Price]

Hi all,

Using Jira Service Management and our project is using the "IT Service Management" template I believe. We don't have a "create sub-task" option when clicking the overflow menu on a ticket. I was wondering if anyone knew how to get it back?

Under "Issue Settings" sub-tasks appear to be turned on:

Is there anywhere else we should be looking?

Thanks.

[John Funk]

Hi Jamien,

Is the Sub-task issue type in your Issue Type Scheme for that project? Here is more information: https://support.atlassian.com/jira-cloud-administration/docs/configure-sub-tasks/

[Jamien Price]

Thanks. This might be getting closer. When I go to Settings > Issues > Issue types the "sub-task" type exists and is related to a number of schemes:

I can't however confirm what scheme is associated with my particular project as when I go to "Project Settings" I expect there to be an "Issue Types" option where I can see what scheme is in use, but that option isn't there:

As such I believe I have no way of knowing what scheme my project is using and in turn can't confirm whether that scheme is related to the "sub-task" issue type or not.

I'm quite new to Jira administration. Does any of that make sense or am I looking at this completely wrong?

[John Funk]

Ah, it sounds like you might be using a Team-managed project. Can you verify if it is Team-managed or Company-managed? Team=-managed projects do not use schemes. 

[Jamien Price]

Thanks John, you're correct, it's team-managed.

I'll confess I'm not entirely sure of the ramifications of that. I am however noticing that a lot of Jira guides I'm trying to follow refer to settings that when I go to hunt them down I don't seem to have. I'm starting to wonder whether being team-managed is potentially the root of a number of these frustrations?

"Team=-managed projects do not use schemes." - does this mean I've lost the ability to control things like turning "sub-tasks" back on then?

[John Funk]

Sorry, I also just noticed that it is a Jira Service Management project. Currently, there are issues with creating a sub-task on those projects. You can vote for and follow the feature request here: https://jira.atlassian.com/browse/JSDCLOUD-1422

So, then comes the next question - why are you trying to create Sub-tasks on a JSM project? Those projects are typically help desk types of projects with queues and don't lend themselves to sub-task creation. 

[Jamien Price]

Thanks for your insight and taking an interest. Long story short my company set up Jira fairly hastily in the last 12mths. We function similar to an MSP (client submits an issues/change request and my tech team actions them). I've come on board and am trying to improve our day to day operations and focussing on significantly improving how we use Jira is going to need to be about 80% of that.

However! I'm starting to learn that Jira really isn't ideal for an "MSP type" operation and caters far better toward software development. With Connectwise we had the ability to add tasks to a ticket to keep track of each thing that needed to be done before the job could be completed. The beauty of Connectwise was it physically wouldn't let you close a ticket unless all the tasks were marked "done".

Jira obviously doesn't quite have that ability, however I figured at the least we could spawn sub-tasks out of a parent tickets as new things popped up. Then at least they would be tracked and not forgotten. At the moment if we get a request from a client and as the job unfolds two more things pop up by the time my tech finishes the original request it's easy for them to forget the "other tasks" that are now buried in-between 10 communications.

I realise I'm kind of trying to "bend" Jira into working the way I want, but god it would be nice to extract a useable product out of it, even if I have to do it in a bit of a ham-fisted way. I somehow can't see us getting approval to change the ticketing systems at this point in time.

Thanks.

[John Funk]

Well, let's see if we can't make you a hero then my friend, because Jira can do all of that itself.  :-)

First, let's talk about the toolset and what they are designed to do. Jira Service Management is for help desk type teams and receiving intake requests, etc. Pretty much what you have in place now. 

And Jira Software is designed for development work primarily. The beauty of it is that's not one or the other, but you can use them together. So let the requests come in using JSM, but then you can spinoff or create a JSW issue that is attached to the original request using an Automation rule. Then your developers can work in JSW as intended and you will not incur the extra costs of also making them Agents in JSM. 

How does that sound? 

[Jamien Price]

Sorry for the delay John, I've been in back to back meetings for the last few days.

Sounds like there could be some potential in what you're describing. I am learning on the fly so correct me if I'm wrong, when you talk about JSW vs JSM - would these two "functionalities" appear in the same login and project for Jira? Or is this something my techs would need to flick between? ie. two different portals?

In my experimentation with making a new project in JSM it does appear that the functionality of the portal changes dramatically based on what template I initially choose. Is what you're suggesting just a case of "accessing functionality" that would otherwise be hidden by default due to the template we're using? Or am I completely off base here?

[John Funk]

Sorry for the lingo - JSM is Jira Service Management project - this is where your portal resides and is the intake portion of requests. JSW is Jira Software project and is where the work will be done and does not have a portal. They are separate project types and projects. 

So, create a JSM project and portal and form to collect the request. Then create an automation rule that fires based on the ticket getting created in the JSM/portal portal project (Issue Created trigger in automation lingo). This rule will create a new issue in the JSW project and link it back to the original portal request ticket. 

Then create another automation rule that will keep the original request ticket updated with information from the JSW project (change status to In Progress, etc.) Then when the JSW work is completed, you can automatically mark the original request ticket completed (i.e. Done or whatever status you use). 

That way your developers don't need Agent licenses for the JSM project (which saves money), and you still get all of the work done. 

Does that make sense? Will that work? 

[David A]

Hello Jamien,

You must dropdown the option "actions menu" in the issue and there appears create subtask.

Hope this helps!

[Jamien Price]

Thanks David,

I'm afraid that when I open the action menu and search for "create" nothing appears:

And when I search "sub" I get a single entry called "sub-task" that simply takes me to the admin settings page for sub-tasks:

I still have no way of actually creating a sub-task.

Thanks.