Link existing child issues to newly created Epic in the same Automation.

[Jack Wiltshire]

So here's the deal. 

I have it set up so that if employees of my workplace email a particular domain it creates an issue on my board. 

What I'm trying to set up is so that if I change a field in that ticket it does the following: 

1) Checks to see if an Epic with the same value as the field already exists 

2) Creates an Epic ✅ 

3) Copies the fields of the issue into the created epic ✅ 

4) Automatically sets itself as the child issue to the newly created Epic 

Can anyone help with this? 

The green checks are what I've been able to figure out in the flow on my own. 

[Trudy Claspill · Accepted solution]

Hello @Jack Wiltshire 

Welcome to the community.

Can you please show us all the components of the rule you have built so far?

Is this in a Company Managed project or a Team Managed project?

You can get information about an issue you have created within the automation rule using the {{createdIssue}} smart value. 

If this is for a Company Managed project, and you have triggered the rule from the issue that you want to make a child of the newly created Epic, then it should work for you to use the Edit Issue action and set the Epic Link field to {{cretatedIssue.key}}

[Jack Wiltshire]

Hey, Not sure what either of those terms means ill be honest. I manage the project myself and it's solely used by me, it's used for non-technical use in creating a task for me to complete regarding compliance and bid proposals. 

This is where I get stuck:

[Trudy Claspill]

When you are viewing the project, in the navigation pane on the left at the bottom it will say if the project is team-managed or company-managed.

Example

This is important to know because the solution is different for each project.

You'll want to get rid of the branch that says "For all created issues". You are not going to need that. Instead you are going to need an Edit Issue action. The details of that action depend on your answer about the type of project.

[Trudy Claspill]

I forgot to ask about the first item in your list.

Which field in the "child" issue holds the value you would use to check if an Epic already exists? And what type of field is that?

And which field in Epics would you compare that value to, to determine if an Epic already existed and a new one did not need to be created?

[Jack Wiltshire]

Okay figured it out! 

4) Automatically sets itself as the child issue to the newly created Epic ✅ 

Did that using {{createdIssue.key}} as recommended thank you for that! 

Now just :

1) Checks to see if an Epic with the same value as the field already exists.

This is ideally to prevent any duplication of Epics. 

[Jack Wiltshire]

Just saw your previous reply regarding my final issue. 

The field in question is called "Client for Epic" this is what I use to determine the "Epic Name". 

This is a context field. 

[Trudy Claspill]

"context" is not a field type.

Is it a text field? A selection list field?

And it would still be very helpful to know if you are working with a Team Managed or Company Managed project. I think you must be working with a Company Managed project because Team Managed projects don't have an Epic Name field in their Epic issue type.

[Jack Wiltshire]

Sorry forgot to say its "Team managed". 

In regards to the "context field" please see the image. 

In terms of the actual field itself, it's a short text field. 

[Trudy Claspill]

Hello @Jack Wiltshire 

I'm dubious about your answers that

- the project is Team Managed and

- that you were successful in making the issue a child of the new Epic by setting the Epic Link field and

- that you want to compare the text in Client for Epic to the Epic Name field of existing Epics.

Epic issues in Team Managed projects don't use the Epic Link field to connect a child issue to an Epic, and they don't use the Epic Name field.

Can you show us the Automation Rule in its current state, and the Audit Log details for an execution where the issue was successfully made a child of the new Epic?

Regarding the step to figure out if an Epic already exists, I would recommend you use the Lookup Issues action with a JQL statement to search for any Epics where the Summary field (because Epic Name isn't used in Team Managed Epics) contains the text in the "Client for Epic" field.

Follow that with an If/Else block with an Advanced Compare to check how many results are returned by the Lookup Issue action.

If the result set size is zero (no epics that match) then execute the components to create an Epic and make the issue a child of the new Epic.

Follow that with an Else-If to check if the result set size is 1 (one matching Epic found) and add steps to make the issue a child of the found Epic

You have to set the Parent field because in Team Managed projects that is the field in the child issue that is used to keep track of the parent Epic.

The tricky bit here is what happens if the Lookup Issues results contains more than 1 match. You can either add an Else to take some actions in that case, or you can make the previous block a simple Else (rather than Else-If). In the former maybe you want to send yourself an email to look at the new issue and manually link it to an Epic. In the latter choice your rule would end up reporting success but neither creating a new Epic nor linking the issue to an existing Epic.

[Jack Wiltshire]

Happy to provide evidence for you, I'm just going by what I see. 

What would the solution be based on the principle I can access "Epic Name"? 

[Trudy Claspill]

Substitute "Epic Name" for Summary and you can use a simple Edit Issue action to set Epic Link.

I would recommend that you also do some experimentation in Advanced Issue Search to see the results for a variety of JQL statements for 

"Epic Name" ~ "<some text string>"

Text comparison sometimes produces unexpected results. You'll want to experiment with it to make sure you have it set up to get the results you expect.

[Jack Wiltshire]

Thanks! 

Sorry if this seems silly but how would I fit that into my existing automation string? 

[Trudy Claspill]

Please post a new image of your Automation Rule as it currently is configured.

[Jack Wiltshire]

[Trudy Claspill]

The new structure for the rule would look like this:

(Ignore the field I'm checking in the trigger)

[Jack Wiltshire]

Perfect, Thank you! 

Whats the part about the email at the end? 

EDIT:

Tried this and the audit log states it was successful however upon testing it would still create a new Epic even if there was an existing Epic with the same name :( 

Cheeky ask, but is there any chance I could arrange a short video call with someone to help me through this?

I sincerely apologise for my "noob-ish" experience with all this. 

[Trudy Claspill]

The first IF is to check if there were no matching Epics. If none were found, create one.

The IF-ELSE is to check if exactly one matching Epic was found. If so, link the issue to it.

The ELSE is where it goes if more than one matching Epic was found. If that happens, I didn't know what you would want to to, so I plugged in a Send Email component. You can send an email to yourself to let you know that multiple potential matching Epics were found, so the issue wasn't linked to anything and needs to be reviewed and linked manually.

You would need to fill in to whom the message should be sent. And you would probably want to put into the message content the ID of the issue that triggered the rule so you would know which one needed to be checked.

As I mentioned earlier, sometime comparing text doesn't give you the expected results. You should spend some time in the Issue Search screen experimenting with searching for Epics by the text in their Epic Name fields to see what happens.

[Jack Wiltshire]

Ah, Maybe what I'm experiencing is the "unexpected results".

If I used a different field or field type for the comparison could this yield better results? 

If so what would you recommend? 

[Trudy Claspill]

Start by reviewing this document on the syntax for text searching. See if any of the information there helps you construct better text searches

https://support.atlassian.com/jira-software-cloud/docs/search-syntax-for-text-fields/

If that doesn't help you, tell us about some of the searches you have tried and the Epic Names of Epics returned in the search results.

But if you want to be able to enter free form text in that field in the issues, you are going to be constrained by the capabilities and oddities of text searching.

In the use case you have, where you want to automate determining if an epic exists or not, I cannot think of any other field type or searching you could do that would not essentially require you to already know if an appropriate Epic existed. That doesn't match up with your use case.

[Jack Wiltshire]

Still no luck I'm afraid. 

At least the linking when created it working now, I guess I can keep an eye out for duplication manually. 

unless you can see any blaring mistakes on my part?

[Trudy Claspill]

If it is not linking when an epic already exists, what are the results of the filter for ?

"Epic Name" ~ {{trigger."Client for Epic"}}

Use a Log action to print that out into the rules Audit Log to see what is actually being used by the Lookup Issue action

Insert that before the Lookup Issue action.

[Jack Wiltshire]

The hope is to get it to link when an epic already exists, it's just not doing it haha. 

This is what the log message pulled: 

[Trudy Claspill]

You have an extra double-quote in front of triggerIssue

[Jack Wiltshire]

Whoops! Thanks,

This is what it's flagging now. 

[Trudy Claspill]

And what happens if you execute the same filter in the Advanced Search Issues screen?

"Epic Name" ~ TEST

[Jack Wiltshire]

Lots of issues come up, but none belong to me or my board: 

[Trudy Claspill]

Can you provide a screen image from the View All Projects screen that shows this project you're working with (DDIL) and the column that says if it is Company Managed or Team Managed?

Can you show us a screen image of the Epic in this project that include "TEST" in the Epic Name field?

[Jack Wiltshire]

Sorry, i have already deleted the "TEST" now as to prevent clutter on the board but I do have this screenshot if this helps. 

I have whited over any business details that need to remain confidential. 

[Jack Wiltshire]

Oh, I also had this with one of the attempts: 

[Trudy Claspill]

Looking at the first screen image I can see that indeed the DDIL project is Team Managed. In that case, the Epics in a Team Managed project don't use the "Epic Name" field and your comparison needs to use the Summary field instead.

For the second image showing the audit log, if the text that is in the Client For Epic field includes spaces in it then you will have to enclose it in quotes in your Lookup

Summary ~ "{{triggerIssue.Client for Epic}}"

And you don't need the quotes inside the curly braces around Client for Epic.

Also, given that the project DDIL is a Team Managed project, setting the "Epic Link" field to make the issue a child of the Epic should not work. Those projects don't use the Epic Link field.

I would love to see the audit log and Epic issue details for a case where this rule caused a new Epic to be created and made the triggering issue a child of the newly created Epic. 

[Trudy Claspill]

I have created a rule that works with a Team Managed project, with one caveat.

• If the text in Client for Epic is a single word, and that word appears in the Epic Summary fields either by itself or as part of multiple words, then the Lookup Issues returns multiple issues.
  • Example
    • Epic 1 Summary: Larry
    • Epic 2 Summary: Larry Lewis
    • Client for Epic: Larry
      
      • Result: Lookup Issues finds 2 matching Epics
    • Client for Epic: Larry L
      • Result: Lookup Issues finds 0 matching Epics
    • Client for Epic: Larry Lewis
      • Result: Lookup Issues finds 1 matching Epic

I also discovered that with a Team Managed project now you can set either the Epic Link field or the Parent field for the child issue, and the child issue will be successfully linked to the specified Epic as a child issue. Go figure! I'm nearly positive that Epic Link didn't used to work for linking child issues to Epics in Team Managed projects.

Here's the rule, showing just the Components:

Notes

• I explicitly add a criteria for my project to the Lookup Issues action.
• For my final ELSE rather than sending an email I'm just using a Log action to record how many matching Epics were found.

For the Edit action in the IF section these are the details:

For the Edit action in the ELSE-IF section these are the details:

I tested the above rule with the following scenarios, in this order:

Client for Epic value	Epic with matching Summary Exists?	Epic Created?	Trigger issue linked to Epic?
larry	N	Y	Y
paul	N	Y	Y
larry	Y	N	Y
larry paul	N	Y	Y
larry p	N	Y	Y
larry	Y	N	N - multiple matching Epics; "larry", "larry paul", "larry p"

[Jack Wiltshire]

Thanks, Unfortunately, it's still creating a 2nd new Epic for the 2nd test ticket. Ill include screenshots for that later on however here is the audit log for the creation of a new epic and then linking the trigger ticket to the new epic as its child. 

The earlier time was the 1st test ticket, this did its job as expected. 

The other is the 2nd test ticket, which again created a new Epic instead of linking itself to the existing epic. 

I think there is an issue with {{lookupIssues.first.key}}.

[Bill Sheboy]

Hi @Jack Wiltshire 

Lookup Issues uses JQL, and when you want more-consistent results to use the .first try adding an ORDER BY to the JQL.

Without seeing your current, entire rule(s), it is also possible there is a timing execution problem in the rule causing this symptom.

Kind regards,
Bill

[Jack Wiltshire]

Thanks, Bill, 

See below, maybe you can advise on what's broken here: 

The updates to the Epic Links are {{createdIssue.key}} and {{lookupIssues.first.key}} respectively. 

[Bill Sheboy]

I notice that your Lookup Issues JQL does not include a project check.  Is it possible there are other issues which have the value in the summary?

Just to confirm, can you post the exact JQL you are using for the lookup...not a screen image?

And if that is not the problem, I wonder if the JQL contains operator is somehow matching/mismatching something else.  You can test that by running the JQL stand-alone in advanced search to see what happens when you expect no second epic to be created:

issueType = Epic AND summary ~ "some example value of your Client for Epic"

Finally, what would you expect this rule to do if the value in Client for Epic is cleared?

[Jack Wiltshire]

Thanks Bill, I did not include a project check as it seems to be adding it itself by the project ID when error I noticed an error code, see the example here. 

Please ignore the incorrect formatting of the JQL I was playing around with a few things: 

The intended purpose of the automation is as follows:

1. WHEN field "Client for Epic" is populated,

2. IF no Epic already exists where "Summary" = "Client for Epic"

3. THEN Create a new Epic AND link the trigger ticket to the new Epic 

4. IF an Epic already exists where "Summary" = "Client for Epic" 

5. THEN Link the trigger ticket to the matching Epic. 

As requested, my existing JQL for the Lookup is

 Type=Epic and Summary ~ "{{triggerIssue.Client for Epic}}"

 Any help figuring out how I can make the above happen would be great, So far the automation can complete steps 1-3 however when I attempt step 4 it will do the same as step 1-3 which made me believe there was an issue with using 

{{lookupIssues.first.key}}

in this situation. 

[Bill Sheboy]

The equals = operator is not supported for the Summary field, and so the contains ~ operator is available.

When you test summary ~ "Client for Epic" it will match on any summary which contains at least all of those words.  It could contain other words and the ordering is not guaranteed.

To test for the exact phrasing, please try to escape the search string with quotation marks , with this:

summary ~ "\"Client for Epic\""

or in the rule this would be"

 Type=Epic and Summary ~ "\"{{triggerIssue.Client for Epic}}\""

[Jack Wiltshire]

Yeah as I said I was playing around with something and realised the equals operator wasn't working, I'm not using that anymore don't worry. 

Have tried as you suggested however still getting the issue of on the 2nd test issue it will still create a new epic despite the "Client for Epic" matching that of an existing epic. 

Please see: 

[Bill Sheboy]

The summary of the epics you are showing are "TEST" and "TEST 2"...

Is that what you expected?

Your lookup issues JQL is so simple, I am unclear how this cannot work...

When you try this, in advanced issue search and not in a rule, what do you observe?

project = DDIL AND issueType = Epic AND summary ~ "TEST"

And, what is the value of the "Client for Epic" field of the two epics you are showing?

[Jack Wiltshire]

The summary of the issues is "Test" and "Test 2", and the summary of the Epics are both called "Test" and are 2 separate Epics DDIL323 and DDIL324... the value of "Client for Epic" on both issues is "Test" so therefore for the 1st Issue it should have created an Epic, which it did, DDIL323. For the 2nd issue, it should have recognised there was already an epic (DDIL323) and linked itself to this, It did not. It instead created another new Epic... DDIL324. 

[Bill Sheboy]

Thanks for clarifying, Jack.

And if that rule is still having a problem missing the first epic (and so creating the other) then either we are missing something obvious or the rule is "broken" internally. 

Sometimes rules get broken due to the number of edits, and other mysterious causes.  The way to check that is to re-create the rule as a new one (not a copy) and see if the problem still persists.

[Jack Wiltshire]

Thanks, Ill give it a go, it can't hurt. 

Ill let you know how I get on. 

[Jack Wiltshire]

@Bill Sheboy Created a new rule and even reversed the order but still not working  

So there must be something we are missing?

[Bill Sheboy]

Yup, and if the rule Trudy provided did not work, I recommend working with your site admin to submit a ticket to Atlassian Support.  Perhaps they can see something in the logging that we are missing.

https://support.atlassian.com/contact/#/

[Jack Wiltshire]

Thank you both @Bill Sheboy @Trudy Claspill 

[Jack Wiltshire]

Thanks to my interal IT guru i managed to resolve the issue. 

It was actually something simple, for my project they are no longer called "Epic" but instead "RFI or Proposal", simply changing that in the string got it to work. 

Thanks again both for your help. 

[Bill Sheboy]

I am glad to learn you got it figured out!

For future reference...confirming you have the correct smart values, etc. for automation rules can sometimes be a puzzle as there are "gaps" in the documentation. 

This how-to article shows how to confirm what smart values are supported and the correct names, spacing, capitalization, type-values, etc.  Basically you find an example issue, call the REST API with a browser, and look at your fields.

https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/