Automation - Link a newly created work item to a previously linked work item

[Eric Younkin]

Hello,

Need some automation expertise here. I have 2 automations that are working perfectly, but can't figure out how to bridge the gap between them:

Automation 1:

When work item is created (SALES-1), create 2 additional work items (OPS-1 and OPS-2), and link them to the trigger issue (SALES-1). This is working perfectly. SALES-1 and OPS-1 and OPS-2 are now all successfully linked together.

Automation 2:

When original work item (SALES-1) is transitioned, create 2 more additional work items (MARKETING-1 and MARKETING-2), and link them to the trigger issue (SALES-1). This is also working perfectly.

So now we have SALES-1 linked to OPS-1, OPS-2, MARKETING-1 and MARKETING-2.

OPS-1 and OPS-2 are linked together as well, as are MARKETING-1 and MARKETING-2, but the OPS and MARKETING items are not linked together.

What I need:

On Automation 2, I want to link the newly created work items (MARKETING-1 and MARKETING-2) to the originally created work items from Automation 1 (OPS-1 and OPS-2). Right now they are only linked to the original trigger issue (SALES-1), but I can't seem to find a way to tell Jira to look at all items linked to SALES-1, and link the new items to those.

Basically, after Automation 2, I want everything that was created with both automations to all be linked together, so you can bounce back and forth between all items.

I'm currently using a Branch for: Linked Work items, Types: All link types and then an Add Link work item to: "Trigger work item". I suspect there is a smart value I could replace "Trigger work item" with on the Link action that would find everything else that was linked to the trigger item (SALES-1), but I've tried several and none seem to work.

Help!

[Bill Sheboy]

Hi @Eric Younkin 

Why and how are you cross-linking all of the work items: OPS-1 to OPS-2, MARKETING-1 to MARKETING-2?  What problem are you trying to solve?

Knowing the answer to those questions may help identify other solution approaches.

Until we know those, and without seeing the specifics of your complete rule #2...You could get the OPS-1 and OPS-2 work item keys using the Lookup Work Item Data with JQL, and then add the links using advanced edit with JSON in two steps.

• trigger: work item transitioned
• ...some other logic, such as condition test
• action: lookup work items, with JQL to find OPS-1 and OPS-2
• smart values condition: confirm that {{lookupIssues.size|0}} equals 2...otherwise one of your assumptions is incorrect and the rule should stop processing
• action: create work item (for MARKETING-1)
  • include an advanced edit with JSON to link to {{lookupIssues.get(0).key}} for OPS-1
• branch: to most recently created work item
  • action: edit work item
    • advanced edit with JSON to link to {{lookupIssues.get(1).key}} for OPS-2
• action: create work item (for MARKETING-2)
  • include an advanced edit with JSON to link to {{lookupIssues.get(0).key}} for OPS-1
• branch: to most recently created work item
  • action: edit work item
    • advanced edit with JSON to link to {{lookupIssues.get(1).key}} for OPS-2

Unfortunately, links must be added one at a time, which is why the extra steps and branching are required.  The branches could be combined to use branching over the most recently created work items (plural), but that seems riskier due to the back-to back edits.

Kind regards,
Bill

[Eric Younkin]

Hi Bill,

To directly answer your question - My primary need for all issues linked together is when a change is made in one area, I need it to be reflected in ALL areas. For instance, Marketing makes a change on their ticket, and it updates the linked tickets in both Sales and Ops. Or Ops makes a change and it updates in both Sales and Marketing. That's the major objective. The challenge is I can't create the Marketing tickets until after the Sales and Ops tickets are created (a later transition), because how they are created depends on the workflow of the Sales and Ops tickets - hence my need to link to the Ops tickets AFTER the fact with a 2nd automation. Complicated, I know.

Right now, when I create multiple new issues in a single automation, I'm using the Create Variable action to set the first item as {{createdIssues}}, and then I'm calling that back after the automation is done, with a last step being a branch for most recently created work item, Link work item to {{createdIssues}} to link the 2 created issues together. Not sure that's the most efficient way of doing it, but it's how I was able to get it to work when creating more than 1 issue and needing them all linked back to the trigger issue and each other.

Tough to give you the whole automation because it's currently 59 steps. Again, it's all working perfectly, but I need to find a way to link the work items from the 2nd automation together with all items from the 1st automation.

I will take a look at yours and Robert's approach below and let you know what works. Thanks for your help!

[Robert DaSilva]

Hi @Eric Younkin , I want to first re-state your challenge, and then provide a potential solution.

Your goal is this:

You are creating work within your Sales project. At the time of creation within Sales, you need two (or more) work items to be created within your OPS project. You have created an Automation rule to handle this creation.

At a later point, when your Sales work item is transitioned to a specific spot, you need two (or more) work items to be created within your MARKETING project. You have created an automation rule to handle this as well.

You are looking to ensure that all of the work gets linked together, such that no matter what ticket you view, you can see all other tickets linked.

• SALES-1 is linked to OPS-1, OPS-2, MKT-1, and MKT-2
• OPS-1 is linked to SALES-1, OPS-2, MKT-1, and MKT-2
• etc

If this is correct, I think we have a simple solution.

My understanding is your second automation rule follows a format similar to this:

• TRIGGER: Work item transitioned
• ACTION: Create work item in Marketing
• ACTION: Create work item in Marketing

If that's the case, I think we can make a small adjustment:

• TRIGGER: Work item is transitioned
• ACTION: Create work item in Marketing
  • Select the Linked Issues field as an entry we want to populate
  • Configure the Linked Issues field to COPY all linked items from the trigger issue
• ACTION: Link work item
  • Configure this to link to the most recently created work item
• Repeat for however many work items you need to create.

The reason this should work is the context of the rule. Because our trigger is action-ing the SALES work item, that's our context. So, the "copy" is taking all the links from the SALES item and adding them to the Marketing work item. Then, the follow-on Link action is still acting on our SALES item, but this time we want to link the Sales to our new ticket.

Here's some screenshot of how this should look. Forgive the rough testing nature of the rule, the structure should work.

and the copy settings for the "Create new work item action:

And finally the "Link Work" action:

Give this a go and let us know if it works out!

Robert

[Eric Younkin]

Thanks Robert, I will give that a try this weekend and let you know how it goes!

[Eric Younkin]

Robert, quick update (because I swore I read a solution like yours before) - I don't have the option to add Linked Issues to the initial "Create" action, because I'm using "Create work item with a request type", not "create item with Issue Type". I'm thinking we are going to need the request type set for many reasons.

Any reason NOT to do it your way and then set request type after-the-fact?

[Robert DaSilva]

@Eric Younkin Ah, did not realize you were creating work within JSM spaces.

The "Create work item with request type" does in fact support setting the Linked Work Items field, but it needs to be part of the Request From in your JSM Space settings. The other limitation is that you cannot "Copy" like I proposed, you can only set the value when using this "Create with request type" action.

What you can try is this:

• TRIGGER
• ACTION: Create with request type
  
  • Set all your regular values here, with the exception of the linked items
• BRANCH: For most recently created work item
  • ACTION: Copy linked issues from TRIGGER work item
  • ACTION: Link work item to TRIGGER work item

• Outside of branch, repeat the above for the second, third, etc.

This change should work. The big note is the context. Because we're now doing linking within a branch, the actions are no longer being taken on the triggering work item in your Sales space, but instead the brand new work item in your Marketing space.

Here are some screenshots showing the new rule layout:

[Eric Younkin]

@Robert DaSilva - this worked! Slight tweak as I just created a regular issue type to use your copy trigger issue link, and then assigned it a request type immediately after, but this worked perfectly!

Now a new, small wrinkle I'd love yours and @Bill Sheboy 's thoughts on if you'd be so kind:

Because I'm copying the linked issues, they are coming over with the incorrect link. Example:

• SALES-1 is linked to OPS-1 and OPS-2 with link type "allocates". This is correct.
• new MARKETING-1 and MARKETING-2 are linked to SALES-1 with link type "relates to". This is also correct (because I set it).
• Because I copied the links from SALES-1, OPS-1 and OPS-2 are linking to MARKETING-1 and MARKETING-2 with "allocates", because that's how they were linked to SALES-1, and those links are copied. This is incorrect. I need to update the links between OPS-1 / OPS-2 and MARKETING 1 / MARKETING-2 to be "invoiced by". This is important in later workflows when automation needs to change only "invoiced by" linked issues.

I can add a branch for Linked work items, "allocates", which successfully identifies the OPS-1 and OPS-2 work items, but I can't seem to change those link types. What I have done to clean it up on the branch is:

-For: Linked work items Types: Allocates

-Delete work item link(s) Allocates

-And: link work item to (Trigger work item)

(this removes the incorrect MARKETING and OPS links, and recreates the deleted links between SALES and OPS successfully)

-And: Link work item to MARKETING (to try and create the correct link between OPS and MARKETING, since this branch is editing the OPS items)

...the problem is, I'm getting the error: "Unable to link work items. At least one of 'id' or 'key' is required to identify an issue"

I've tried using most recently created item, as well as the variable ({{createdIssues}}) that is working successfully in the automation before this branch, but to no avail. I'm thinking this is because I'm now in a branch, and it can no longer see the 2 MARKETING issues I've just created, but I can't figure out this last piece of how to link them together.

Basically, how can I reference issues created earlier in the automation in the branch I'm now in to complete the last links.

Thoughts?

[Robert DaSilva]

Hey @Eric Younkin ,

I think it might make sense to spin this out into a new automation rule against the Marketing project, where you are noticing the links are incorrect.

I haven't had a chance to test this, but this is my thought process:

Rule: Fix copied links from auto-created tickets

NOTE: You'll want to make sure this rule can be triggered by other rules.

• TRIGGER: When issue created OR when work item linked
  
  • You may need to test, the links may be added at time of creation or shortly afterwards, so the "created" trigger may not be sufficient
• BRANCH: For each linked issue
  • CONDITION: Link type == incorrect link type
  • CONDITION: Link issue is part of project with incorrect link
  • ACTION: Create Variable for the work item
  • ACTION: Delete link
  • ACTION: Edit trigger issue to add link, with corrected link type, with issue captured in the variable

Give that a test, and let me know if it works!

Robert