Lookup for Automation

[Robynne Barnard]

Hi everyone,

I am looking to use automation to create a rule that when an issue is created via Request Type it will {{LookupIssues}} based on certain criteria and depending on that lookup it will then need to either create a sub-task in the existing issue or create a new parent task. Whether this is possible I am unsure...

However, when I say {{issue.parent}} it does not seem to look for only the parent issues and seems to come back with all the issues and same occurs when I try with {{issue.parent.resolution.Unresolved}}. We would need to use multiple JQL lookup's and from what I have seen the suggestion is to create variables. 

Please if some guidance can be given it will be appreciated! 

Thank you!

[Mark Segall · Accepted solution]

Hi @Robynne Barnard and welcome to the community!

Can you please provide a little more context on this?  Specifically...

• What JQL are you trying to execute?
• Can you elaborate on looking for {{issue.parent}} on a Request Type?  The term Request Type implies JSM which typically doesn't use parent.
• Any additional information you can provide about the rule
  • What is the expected trigger
  • What conditions
  • What actions

[Robynne Barnard]

Hi @Mark Segall , 

The JQL I am trying to look for is the parent issue, as well as the resolution. 

And  correct Request Type does relate to JSM, but for our purposes we require sub-tasks as issue types in our projects. Hence, we have added them and they are working well. 

In terms of the rule:

Trigger: Create issue

Conditions: Request Type = XX or Issue Type = XX

Actions: Lookup issues and create an issue 

[Mark Segall]

Thanks for the additional clarity, but I'm still not fully following the architecture.  I understand using sub-tasks with requests.  However, what I'm trying to understand is where this comes into play in your rule.  Let me pose a hypothetical:

New request has been generated from the portal.  This triggers the rule, but the request type has no parent or child issue at this stage.  It's simply an orphan request type.  How is the rule expected to identify a parent/child issue from here?

[Robynne Barnard]

So, that is what we are trying to figure out. We would ideally want it to identify the parent issue based on an Asset Field and a parent issue that is in resolution open. 

Ideally the request is created in the portal and then we would want it to look for an issue that matches an Object in an open parent issue and create a sub-task within that parent task if it finds one. 

[Mark Segall]

Ok - This is clearing up for me.  Thank you for being patient with my line of questioning. So, I have one more:

A new request has been created.  What is meant by "parent"?  Are you putting your requests into Epics or are you creating some type of logical link to another issue that simply plays the role?

[Robynne Barnard]

Not a problem. It has been a bit of a confusion for myself too. 

No Epics used that I know of. 

[Mark Segall]

So, what are you meaning by "parent" as it relates to a request?  

...depending on that lookup it will then need to either create a sub-task in the existing issue or create a new parent task

This is where I'm still not clear on your question.

[Robynne Barnard]

The Request would be the "parent" issue. 

[Mark Segall]

Thanks, but I'm still trying to put this together as I'm still stuck on your meaning for that part of the question I quoted above.

[Robynne Barnard]

Essentially we want the lookup issues to return whether there are any existing 'parent issues'/ requests that have that particular Asset Field in it. And if it does not find anything matching that field then it would need to create a new request/ parent issue. 

I hope this makes sense. I am a bit new to it all still. 

[Mark Segall]

Ok - I'm getting a better understanding now (thanks for your continued patience), but  I think what's had me hung up is that you should never run into not finding the parent issues situation because sub-tasks cannot be created without having a parent.

Let's walk it through with clearly defined steps in a process:

1. Request is created and as part of issue creation it is linked to an asset
2. That request is evaluated against existing requests to see if any others exist linked to the same asset
   -- I think this is where I'm on the same page... Now the part where things are still fuzzy
3. If no like issues exist, you want...
   1. a new request to be created?
   2. a new sub-task to be created?

[Robynne Barnard]

You hit the nail on the head. That is what we want to do.

[Mark Segall]

Great.  So in that case, you'll want something like this:

• TRIGGER: Issue Created
• CONDITION: Issue Type != Sub-Task
• ACTION: Lookup Issues
  - We'll look for existing requests with the same asset
  
  • YOURASSETFIELD IN ({{issue.YOURASSETFIELD}} AND issueType != Sub-Task
• IF CONDITION (Advanced)
  - We'll see if we have at least 1 other issue linked to the same asset and create a sub-task
  • {{LookupIssues.size}}
    Greater Than
    0
  • ACTION: Create Sub-Tasks
• ELSE
  - The else condition is for If no results were found in the lookup action. This is where I'm still not quite sure what you're trying to do, but if you need to say, create a new request, you'd do that here.
  
  • ACTION: Create Service Request

[Robynne Barnard]

Good morning @Mark Segall , 

I gave it a try and it is progress. The error it gives me is that it either does not exist or I do not have permission to view it. This is how I have set it up. Maybe you can see any errors I have made? 

[Mark Segall]

Your Lookup query needs a tweak.  Try this:

cf[10923] IN ({{issue.customField_10923}}) AND issueType != Sub-Task

[Robynne Barnard]

Hi @Mark Segall so it ran successfully, but it did not find "parent issue" and create a sub-task in that related parent issue sadly. 

I will keep trying though

[Mark Segall]

Can you please share a screenshot of the audit log for the rule?  This will help me get better understanding of what's happening vs your expectation.

[Robynne Barnard]

Sure

[Mark Segall]

Ok - So in this instance it found no matching issues.  If this is an expected outcome, you'll want to update your ELSE condition to include whatever you want to have happen which is where I'm still not 100% sure I understand.   You'll want to add the appropriate action as a component under that Else condition:

• Create a request
• Create a sub-task on the issue that triggered the rule
• Create a request with its own sub-task

[Robynne Barnard]

What is happening is that when I create the issue in the portal. I want it to look for is the customfield outlined in other parent issues and if there are parent issues that already exist with the specified customfield it must create a sub-task in that issue. 

[Robynne Barnard]

If nothing is found we want to trigger a new request to create a new parent task based on the customfield. 

[Mark Segall]

Got it - I think this filled in the last thing that I was fuzzy on.  So, to make sure I'm on the same page:

You have at least 3 issue types in play for any given asset:

• Task: Not to be confused with a request, this serves as a "parent" that requests can reference with x information
• Request: Something that comes in from a customer
• Sub-Task: Internal activity that needs to happen against a request

If I'm understanding this correctly, you'll just need to add a new ACTION: Create Issue under the Else condition.  In that create issue action:

• Select your custom field and set it to copy from the trigger issue
• Summary: Set to whatever you want
• Description: Set to whatever you want
• Repeat for any other fields that you typically set

[Robynne Barnard]

Hi @Mark Segall , 

Thank you for all the assistance. Sadly, still no luck. It keeps rendering the error that it cannot find the Asset custom field. Will keep trying, but may explore other avenues as well. 

[Mark Segall]

Hmm... Maybe try using = instead of IN...

cf[10923] = {{issue.customfield_10923}} and issueType != Sub-Task

[Robynne Barnard]

Hi @Mark Segall , I hope you are well. 

Sorry for the delayed feedback. 

I have managed to refine the automation and it is looking up the exact parent issue I am looking for now. 

However, it i creating the sub-task in the newly created parent issue which is created from the request. I thought perhaps I could use a move action to move the sub-task to the issue that resulted from the lookup issue portion? However there is no action at present that allows you to move an issue in automation. 

I thought maybe I can try and use Advanced fields. 

Please see attached. So essentially we want to move BORROW-317 to be a sub-task in BORROW-150 and not create a whole separate sub-task. 

[Mark Segall]

Hi @Robynne Barnard 

Yes - You need to change the parent in the advanced portion of the Edit Issue:

{
   "fields": {
      "parent": {"key":"{{lookupIssues.key}}"
      }
   }
}

[Robynne Barnard]

Hi @Mark Segall , 

Slowly, but surely, making progress. I have the following issues when adding the above to advanced fields. 

Any ideas on how to go about it? Not sure what the error means exactly. 

[Mark Segall]

That message means that the syntax is right, but the link is breaking the Jira hierarchy (e.g. making a task a child of another task).  Can you please confirm that when you say, "Sub-Task" that you actually mean the "Sub-Task" issue type? 

If it is any issue type other than sub-task, this approach won't work and instead we'll need to look into some type of linking strategy to create a logical parent/child relationship rather than one that is enforced (which is how the Parent field works)

[Robynne Barnard]

Hi @Mark Segall , 

Yes, we created a sub-task issue type named Borrow (ST). Do you think this will cause an issue? 

[Mark Segall]

Hmm... That shouldn't be a problem, but perhaps its trying to set itself as a child of another issue type that is a sub-task issue type category?

[Robynne Barnard]

So the issue that we looked up in the first part of the automation is what we want to 'move' the sub-task to. And that issue is a Parent issue that is why I am a bit perplexed. Maybe I just need to play around with it a little more... It is getting close and I just need that one missing piece and it will slide into place - I HOPE!

[Mark Segall]

Hmm... I know changing the sub-task parent should work because I've tested it successfully in my personal environment.

Can you please share a screenshot of the Edit Issue action so I can make sure everything looks ok?

[Robynne Barnard]

Hi @Mark Segall please see attached. 

[Mark Segall]

Thanks for sharing... I see the issue now. 

You won't be able to convert an issue to a sub-task.  As a workaround, you could do this...

Delete the Edit Issue component from your rule and replace with this:

• ACTION: Clone Issue
  
  • Issue Type = Borrow (ST)
    Since this is a sub-task issue type it will pop up a Parent Issue option
  • Parent Issue = {{lookupIssues.key}}
  • (Optional) Linked Issue
    • Clones | Trigger Issue
• ACTION: Transition Issue (To Closed)

This will clone the issue and link it to the trigger issue and close out the trigger issue.

[Robynne Barnard]

@Mark Segall Yay!!! It worked!! AMAZING! Would it be possible to rather delete the trigger issue instead of just closing it? And then delete the link? 

[Robynne Barnard]

That way we do not have duplicates cluttering anything. 

[Mark Segall]

There is definitely a Delete Issue action if you want to go that route.  My personal preference is to not delete due to its destructive nature.  

[Robynne Barnard]

@Mark Segall Let me try it with ways and see which works best. We just want to avoid duplication and risk of things being done twice. Thank you so much for your help and patience!

[Robynne Barnard]

Hi @Mark Segall , I hope you are well. 

I seemed to have hit another snag with my automation. 

After the lookup condition I am trying to get the automation to create a NEW Request if there was no results rendered in the lookup, but that renders errors and does not create anything. 

I tried adding it into the "Else" section but still no success do you have any suggestions? I cannot even seem to create sub-tasks beneath that. I have tried branches, I have tried pretty much all I can think of and thought maybe you would have a suggestion. Thanks in advance.

[Mark Segall]

Can you please share the screen shot of the error entry in the audit log and a look at the create issue action you're trying to employ?

[Robynne Barnard]

So it will create an issue in this instance, but I have set it that it deletes the issue for the lookup as we have a cloned sub-task, as we set last week. 

So if I do not delete it then it causes duplication with the lookup automation, but then causes chaos when a new issue needs to be created and no lookup is found. 

[Mark Segall]

I'm not quite sure I understand all of the components under the Else condition.  You should only need to have the Create Issue action under the Else condition.  The error is indicating that you're trying to create an issue type that is a sub-task but not providing a parent key.  I believe the parent should simply be set to the trigger issue.