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; } } }

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!

Accepted answers

Mark Segall

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

All comments

Mark Segall

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.