Assign sub-tasks automatically when a service request is created

[Jason Knight]

I have monthly service requests creating in the scheduler for patching etc.  I'm able to have them open up directly in the appropriate team queue but can I have it assigned to an individual as well without the service desk doing it?

[Jack Brickey]

@Jason Knight, to provide you w/ the best response it would help to understand more about your requirement. Are you wanting to assign all sub-tasks to a single individual or do you want to do this on a conditional basis. If the latter what are the conditions? BTW, I'm not sure what you mean by "having the service desk doing it". Do you mean to say you don't want an Agent to have to set the Assignee but rather have it automatically done?

[Jason Knight]

To step back some...i'm new and the previous service desk mgr setup Jira.  So i'm learning.  :)  So we have the scheduler creating our monthly patching service requests and they were dropping into SD queue and my team would move the request, assign it etc.  I'm able to have it drop into the appropriate support team queue but either my SD team or my server eng has to go out, find them and assign them to individual.  Since we have a good dozen or so monthly SR's I'd like them to just auto assign to an individual if there was a way to place the logic in place.

[Jack Brickey]

Thanks Jason and no worries we all had to start at the beginning. You will learn quickly. :-)

So fully understand what you have conveyed. However, my question still is unanswered so let me rephrase. 

Who get's assigned an issue? How do you determine the owner of an issue?

The reason this is important is that if you wish to automate assignment then you need to do so by checking the variables.

Example:

Let's say you have 4 different people that will be assigned the issue based on the area associated w/ the issue. You could use the Components field to do so and here is how:

1. Define Components, ex. CompA, CompB, CompC, CompD
2. Define the Component lead, ex. CompA > PersonA, ....
3. Make Component field required when opening issues

Now this may not be the solution for your scenario. I just wanted to illustrate the concept.

Again, if you only have 1 person that would ever get assigned issues or if they deal w/ the vast majority then you can make them the project lead and default all issues to the project lead.

There are other solution, just need to understand more about your situation before I can suggest the 'best' solution.

[Jason Knight]

Yeah so based today on the title we know who gets what. Windows patching - Kirk, Linux - Jeff etc.  So I guessed if I could get it to a defined field I could tell the system how to assign.  But the way our system was deployed I'm not seeing any components field.  

[Jack Brickey]

You could use automation (addon like Automation for Jira) and check the Summary field. I'm not a big fan of automating on free text but since all you are doing is setting an Assignee and then if wrongly assigned the person could reassign then harm is low  except for delays. I would certainly recommend using a field (Components or a new custom field) w/ fixed values if possible. However, this will working for request created via portal or the application itself but not for email requests since emails have no concept of required fields beyond Summary and Description.

As for Components field, it exists and simply needs to be exposed to the Create screen and the project lead or admin can add components.

[Jason Knight]

You have been very helpful!  We do have the automation for jira so i'll learn up on that with building new or doing the edits to pull in the fields I need.  Yeah our users use the portal or call.  No email so will be good there.

I'm used to running a desk with a tool like servicenow or manage engine where it is all built or I have an admin of the tool. :)  I'm enjoying learning this tool.  thanks again for the help

[Krishnanand Nayak]

You can do that in the workflow, on the Create transition. There will be post function for assigning it to a user.