Automatically add request participants to trigger issue

[Marcel Jünge]

Hi, 

i am currently working on an automation that automatically adds request participants to the trigger issue.

The trigger issue is an ITSM request via the portal. When the request is created the automation looks up related issues in a JIRA project and sends notifications to the user selected in the field "Asset Owner". So fine so good.

Now i want the users in the field "Asset Owner" to be automatically added as request participants to the trigger issue. How do i have to edit my current automation? (See image). Thx in advance. 

[Bill Sheboy]

Hi @Marcel Jünge 

You could use the Edit Work Item action with a dynamic JSON expression to add more Request Participants.  For some additional details:

• the rule actor needs to be someone who is an Agent to add to Request Participants
• you may need a condition to confirm your source field is not empty
• this KB source describes how to construct the JSON for adding to Request Participants: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Multi-user-picker-custom-field
• your rule would iterate over the values in the source, "Asset Owner" custom field to build the JSON
• to identify the custom field for Request Participants, please use this KB source: https://support.atlassian.com/cloud-automation/docs/find-the-smart-value-for-a-field/
• finally, I recommend adding a Re-fetch Work Item Data action immediately after the trigger to reduce the chance of racetrack timing errors; that trigger can start a rule before all data is ready for use

Your final expression will likely look like this, where customfield_12345 is the Request Participants and customfield_67890 is your "Asset Owner":

{
  "update": {
    "customfield_12345": [
      {{#triggerIssue.customfield_67890.value}}
        {
          "add": {
            "id": "{{.}}"
          }
        } {{^last}}, {{/}}
      {{/}}
    ]
  }
}

Kind regards,
Bill

[Arkadiusz Wroblewski]

@Bill Sheboy 

Kind of I had feeling you will look Here. It looks like Automations summoning you 🤠😅

[Marcel Jünge]

Hey, thanks for your answer.

I have a question: According to the JSON expression the participants field would get updated with the value of the field of the trigger issue..right?

Maybe i am misunderstanding this but i wanted the participants field to be updated with the asset owner field values. The asset owner field is not in the trigger issue (ITSM request) but in the "Look-Up" Jira issue in the other project.

Thx.

[Bill Sheboy]

Hi @Marcel Jünge 

My example was from the trigger issue / work item, and you could certainly use another source...such as from a lookup, branching, etc.

I recommend testing to confirm you get what you want:

• get the other work item which has the field
• write the custom field value to the log to confirm it works as expected
• pre-build that JSON with the updated source, storing it with Create Variable, perhaps named varJson
• write the variable to the log to also confirm it is valid
• use the variable name as the JSON to update your participants: {{varJson}}

[Marcel Jünge]

Hey,

thanks. But honestly i don't know exactly what to do. May i ask you to sent me a screenshot of a "Test" automation you build that does exactly what i want? I fear that it is a bit too complicated without actually seeing it... 

Especially the last step "update" is confusing to me.

In the image you can see what i currently created in the rule. Thank you very much. Much appreciated. 

[Bill Sheboy]

1) Which work item are you trying to update: the trigger one or something else?

2) Which work item is the source of custom field to update the target work item to update (from question #1 above)?

Let's assume you want to update the trigger work item and get the source data from another one.  In that case, the rule would not use branching.  Instead, use the Lookup Work Items action with a JQL expression to find the source data, and then build the JSON to update the trigger work item with a Edit Work Item action.

And, please carefully re-read my first post in this thread: you are using the Work Item Create trigger, and because that has racetrack timing problems:

• Add a Re-fetch Work Item Data action immediately after the trigger
• Never use conditions inside of triggers as they will work unpredictably because of the racetrack timing problems.  Instead, add the conditions after the re-fetch action

Thus, the rule outline could be:

• trigger: work item created
• action: re-fetch work item data
• condition: to check the issue type
• action: lookup work items, to find that source field
• smart values condition: to confirm the lookup found one-and-only-one item
  • first value: {{lookupIssues.size0}}
  • condition: equals
  • second value: 1
• action: create variable to build the JSON expression using the {{lookupIssues.first.yourCustomField}} ...
• action: edit work item data, to use the JSON to update the trigger work item

[Arkadiusz Wroblewski]

Hello @Marcel Jünge 

First please specify, Which field Type are your ” Assets Owner "?

[Marcel Jünge]

Multi-user

[Arkadiusz Wroblewski]

@Marcel Jünge 

@Bill Sheboy  already provided you good answer. 

What you should remember branches on multiple issues run separately, so you shouldn't use branch to build the participant list on the request. 

Keep the email inside the branch, but add the Request participants update outside the branch on the trigger issue.

Take advices from @Bill Sheboy and play a little with that.