Automation Rule called by Incoming Webhook - how to get data returned to caller

[Trudy Claspill]

I have an automation rule that uses the REST API to retrieve some information from the user/search endpoint. This process needs to be used by multiple other Automation Rules, so I thought to set up this rule with an Incoming Webhook trigger. 

What I haven't yet discovered how to do is to return data from this Automation Rule to the ones that call it.

I found a few other posts with this same question.

One from 2021 in which @Bill Sheboy listed a change request that is no longer publicly visible, or just not accessible to me.

https://codebarrel.atlassian.net/browse/AUT-1031

Another one from 2024 that got no responses.

https://community.atlassian.com/t5/Jira-questions/Incoming-Webhook-Response/qaq-p/2654459

[Matthias Gaiser [K15t]]

Hey @Trudy Claspill

I think, there's no easy answer to it. I'd think about these two ways how to solve it:

• Splitting up the automation rule
  • You split up the calling automation rules into two parts:
    • The part before calling the REST API which ends with calling the REST API rule
    • And the part afterwards which starts with an incoming webhook trigger. Your first part of this rule sends the url of this web trigger as an argument to the REST API rule
  • Your REST API rule is setup with the incoming webhook trigger, performs its rest call and in the end sends the web result to the url which it got, resulting in the second part to be called.
• Wrap the REST API call in a simple Forge app
  • In Forge apps, you can call all sorts of REST APIs. So you could offer a web endpoint which calls the REST API you desire and directly return the desired parameters
  • Then you can use the result directly in your automation rules.

Not sure if these answers are really a solution and simplification to your setup, but I guess that's up to you to decide.

Cheers,
Matthias.

[Bill Sheboy]

Hi @Trudy Claspill 

Yes, and...to the suggestions from @Matthias Gaiser [K15t] 

After the old CodeBarrel backlog was hidden from the public, some of the issues were recreated in the AUT backlog (i.e., apparently not cloned, and so losing valuable info!).  Here are a couple asking for the ability to return data from Incoming Webhook Trigger rules:

https://jira.atlassian.com/browse/AUTO-71
https://jira.atlassian.com/browse/AUTO-1402

For the scenario you describe, 2-3 (or more) rules may be needed, as Matthias describes with the splitting scenario:

• 2 rules
  • As described above by Matthias
• 3 rules (This is an extension of what Matthias describes)
  • First rule needs the repeatable behavior, and that triggers the Second rule with Send Web Request
  • Second rule with an Incoming Webhook trigger, making some change to issues / versions / etc.
  • Third rule, based upon some issue / version / etc. changing trigger, start the third rule

Kind regards,
Bill

[Trudy Claspill]

Thank you for the suggestions @Matthias Gaiser [K15t] . While both sound like they would work technically there are constraints on the scenario that eliminate the Forge app option. Your other suggestion has given me a different perspective on the scenario that I might be able to use, though.

[Trudy Claspill]

Thank you for your suggestions @Bill Sheboy 

The option to have the first rule execute the repeatable behaviour rule (aka RBR) is, unfortunately, not viable in our scenario (more details below).

I am considering if I can have the rules that need the RBR call the RBR at the end of the rule to update the issues.

Here is the scenario:

1. User in Slack executes a Slack command to do something in Jira.

2. The client has some custom code processing the Slack commands. The code lives in AWS, and I don't have access to it.

3. Currently the Slack user's Display Name (from Slack) is passed to the custom code.

4. The custom code calls any one or more of dozens of Automation Rules in Jira to take action against issues.

5. In some cases this includes inserting the initiating Slack user into some Jira User Picker field (like Reporter). The display name appears to be some form either of first.last or the first part of the user's email address. I'm still trying to get confirmation on this.

6. In Jira DC it works for them to take the Slack user display name data and put that into a User Picker field. Jira natively is able to resolve that to the actual Jira user account. 

7. We are migrating the client to Jira Cloud. Step 6 doesn't work in Automation Rules in Jira Cloud. We need to use either the user's email address or Atlassian Cloud Account ID.

8. Modifying the Slack user display name is not an option.

So, my RBR is a process to call the user/search endpoint with the Slack user display name, and parse the results to find the matching Atlassian Cloud Account (if present). Then, ideally, I would like to pass that account ID or email back to the calling rule.

Since I can't pass it back, I will be reviewing the rules that need the RBR to see where they have been using the Slack user display name. I'll try to determine if I could add a call to the RBR at the end of that process and update the fields in the issue where the data was used.

The client had said modifying the custom code processing the Slack commands was not viable in the time frame before the planned date for the production migration to Cloud. We are striving to not delay the schedule, but need to have a resolution for this in order to proceed.

[Bill Sheboy]

Thanks, Trudy.  The part I am not quite following: if the Slack ID already existed in Jira would the RBR be necessary?

I was helping with another question to add Slack ID values as entity properties to Jira users to ease back-and-forth messaging.  There is an old article on this for bulk-loading them, and my approach is a one-off to load smaller ID sets with the REST API.  Here is the info, in case it helps:

• https://community.atlassian.com/t5/Automation-articles/Mention-someone-directly-in-Slack-via-Jira-Automation/ba-p/1528605
• https://community.atlassian.com/t5/Jira-questions/Iterate-through-JQL-result-of-issues-extract-certain-fields-and/qaq-p/2915932

[Trudy Claspill]

Hi @Bill Sheboy 

The part I am not quite following: if the Slack ID already existed in Jira would the RBR be necessary?

It is the Slack Display Name for the user that is coming through. I don't know if that is synonymous with the Slack ID.

Let us say the Slack Display Name is "trudy.claspill"

For this client, in an Automation Rule in Jira DC, setting the Reporter field to "trudy.claspill" worked. Jira DC could resolve that to a user account in Jira DC.

In Jira Cloud the Reporter field (or any user picker/people field) can be set only using values that are a user's Atlassian Cloud Account login (i.e. email address) or a user's Atlassian Cloud Account ID. Trying to put "trudy.claspill" into the Reporter field in an automation in Jira Cloud does not work. That cannot be resolved to an Atlassian Cloud User Account by Jira.

Thanks for the additional references. I'll take a look at those.