Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Cloud Automation Rule To Append Request Participants From Linked Tickets

Dwayne Hammond
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 8, 2024

Hello,

I've been exploring options to improve how our team handle client requests and have hit a hurdle on one idea. Hoping to get some clarification if I am missing an approach or if my research so far is correct in that this cannot be done cleanly.

The requirement is as follows: when a ticket of a specific Request Type transitions from status A to B, append the Reporter(s) and Requested participants from all linked tickets to the trigger issue. All required issues and tickets are in the same Project.

An example:

  • Issue SD1 has Reporter 'Ben' and Request participants 'Jane' and 'Jim'
  • SD1 also has two linked tickets, SD2 and SD3
  • SD2 has Reporter 'Bob' and Request participants 'Adam'
  • SD3 has Reporter 'Tim' and Request participants 'Sally' and 'Bill'
  • Issue SD1 transitions from status A to B and triggers the automation
  • The Request Participants field on SD1 is appended to include both Reporters and all Request participants from SD2 and SD3
  • i.e. SD1 Request Participants goes from ('Jane', 'Jim') to ('Jane', 'Jim', 'Bob', 'Adam', 'Tim', 'Sally', 'Bill')

For the most part I can get this to work with the below rule:

  • Trigger on status change from Awaiting Approval to Awaiting NOC
  • Request Type = Client Update and linked issues present
  • Create smart variable LinkedReporter initialised as NULL
  • Create smart variable LinkedParticipants initialised as NULL
  • Branch
    • All link types within same Project
    • Request Type is App Support
    • Create smart variable LinkedReporter using issue.reporter.accountId
    • Create smart variable LinkedParticipants using issue.Request Participants.accountId
  • Set Request Participants to Copy from issue (retains existing) as well as LinkedReporter and LinkedParticipants

This works fine with zero or one linked ticket, but since the Branch runs parallel to the rest of the rule if there is more than one linked ticket the variables are still NULL when being used at the end. I can see that this parallel behaviour is expected and that without adding bloat (e.g. web request) there's no way to create a wait/delay.

I'm hoping that there might be a cleaner solution for what I am trying to do that bypasses these limitations though. What I've made above is done purely from searching online and testing so there's a good chance there is a simpler solution somewhere.

Thanks in advance!

2 answers

0 votes
Kalyan Sattaluri
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 8, 2024

Hello @Dwayne Hammond 

As @Ste Wright 

You dont need branch.

You can do lookupIssues.

Assign your variables (LinkedReporter & LinkedParticipants) values as he has shown.

Finally, Without seeing the values, I dont think you can directly assign these variable values to be added to the trigger issue like you are doing.

I believe you need to do "Advanced Edit" and format your JSON as per Multi-user field syntax. (*I may be wrong and you can directly assign*)

So please modify your rule, log the variables and share with us both the rule and audit so community can help.

0 votes
Ste Wright
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 8, 2024

Hi @Dwayne Hammond 

You could try using the "Lookup Issues" action?

You could...

  • Lookup issues, using a linked issues JQL function - eg. issue in linkedissues("")
  • Refer to the trigger issue's key using smart values - eg. issue in linkedIssues("{{triggerissue.key}}")
  • Create the variables using the lookupIssues results, which can be multiple users rather than singular - eg. {{lookupIssues.reporter.accountId}}

This should allow you to modify "Request Participants" using multiple user results, rather than singular ones.

Ste

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events