nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Branch concurrence issue in JSM automation

Vina Wu

Could you please help on below Branch concurrence issue?

I'm a developer of the team-managed JSM project in jira cloud.

Now my automation rule for adding "request participants" is working well except when many(maybe >4) people need to be added.

rule purpose: add the emails in JSM Forms field to Request participants field.

rule details: it's working well when 1/2/3 people need to be added.

it's not working well when many people need to be added. you can see just 3 of 7 been added from the issue history. seems the first 4 concurrence and some of them didn't been added.

i already add the delay/re-fetch actions in automation rule, but still the same question.

Could you please help on how can i add multiple accounts?

thank you.

Accepted answers

All comments

Scott Boisvert

Whats in your audit log when it fails? Is there any kind of error displayed or is it skipping?

Vina Wu

@Scott Boisvert audit log shows as success

Markus

Hi @Vina Wu,

It might be a bit out there but maybe the problem isn't in your automation but in the Custom Field you are editing. Depending on how much Characters you are adding it could be that it's the max Character Limit that is preventing more than 3 Participants. If the Custom Field is a Short Text Field then you are limited to 255 Characters.
Or if the Field is a User Picker then i'd check if there is limitation on how many Users may be selected in that Field.

Best Regards,
Markus

Vina Wu

the Field is a Long Text Field. anyway, the problem is now automation rule can get all the 7 accounts/people, but only 3 of them been added to "Request Participants" field. maybe because the Branch concurrence.

Mihai_LeanZero

Look at the issue history. Four entries "None -> one user", back to back. Four branches each saw an empty field, each wrote its own user, last writer wins. Every edit did succeed, the audit log is right.

Branches run in parallel. Doc: "Branches on multiple issues (such as 4 sub-tasks) will run in parallel with no guarantee one will finish before the next one starts." (https://support.atlassian.com/cloud-automation/docs/jira-automation-branches/) Advanced branching gets no carve-out. Delay and Re-fetch move one branch's own clock, not its siblings'.

What I'd try instead of the Edit: a Send web request inside the branch, POST https://<site>/rest/servicedeskapi/request/{{issue.key}}/participant with body {"accountIds":["{{webResponse.body.first.accountId}}"]}, same auth as the user search, as long as that token's user can manage participants on the request (an agent can). Per the doc it "adds participants to a customer request" (https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-request/#api-rest-servicedeskapi-request-issueidorkey-participant-post). One add per call. No rewrite of the whole field.

Nothing documents that one as safe under parallel calls either.

Arkadiusz Wroblewski

Hello @Vina Wu

You running into limitation [JSWCLOUD-22614] The advanced branch runs in parallel leading to unpredictable behaviour in the final result - Create and track feature requests for Atlassian products.

and [AUTO-2220] Workflow Orchestration: Sequential or Ordered Branching - Create and track feature requests for Atlassian products.

You will likely need a redesign that includes a single GET request for the account ID. The Jira Service Management Cloud REST API

Best,

Arek🤠

Vina Wu

thank you for the suggestion.

i tried, "Edit part" replaced by "send web request". but also got the parallel problem.

Mihai_LeanZero

@Vina Wu my endpoint idea didn't help. Judging by the history, the server still reads the field and writes it back per call, so five parallel calls race like the Edit did. No atomic add is documented.

No sequential branch either. AUTO-2220 "Sequential or Ordered Branching" is Gathering Interest at 62 votes, JSWCLOUD-22614 was closed as a duplicate.

The only serial thing automation has is a rule that triggers itself. Number field "Participant index". Rule A, on the existing trigger, sets it to 0. Rule B fires on Value changes for that field, Allow rule trigger on. Condition {{issue.Participant index}} < {{issue.ParticipantsforAIP.split(",").size}} (or whatever field your ParticipantsEmail variable is built from). One GET user/search for {{issue.ParticipantsforAIP.split(",").get(<index>)}}, one POST participant with that id. Then Edit the index to {{issue.Participant index.plus(1)}}, which fires B again.

Doc says "0 denotes the first element in the array" (https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/) and "If a rule triggers itself immediately, it will be allowed to run 10 times before it's execution is stopped and marked as a LOOP" (https://confluence.atlassian.com/automation/service-limits-993924705.html). So 7 fits, 11 wouldn't.

Two spots aren't documented, test on one ticket first. Whether .get() takes a smart value as the index, the doc only shows a literal 0, maybe a Create variable step is needed. And whether the trigger fires on the rule's own edit, Allow rule trigger only mentions other rules.

How many emails does the biggest form carry?

Mihai_LeanZero

@Vina Wu scrap the index step, .get() won't take a smart value as the index.

I tested this on a scratch site. get(issue.Counter) and a Create variable then get(idx) rendered empty, get({{idx}}) errored the whole action, only a literal like get(1) returns anything.

The self trigger does work. With "Allow other automations and user actions to trigger this flow" on (under the flow's Settings) the rule re-fires on its own edit, 10 runs about 2 s apart, then "execution loop was detected... Chain length: 10" in the audit log.

So no index. Text field, call it Remaining. Rule A on the existing trigger copies the email list into Remaining.

Rule B, trigger Value changes for Remaining, condition Remaining is not empty. One GET user/search for {{issue.Remaining.split(",").first}}, one POST participant with that id, then Edit Remaining = {{issue.Remaining.substringAfter(",")}}, which fires B again.

Three addresses ran a, b, c, then a fourth run where the condition was false. Remaining went "a,b,c" to "b,c" to "c" to empty, so it ends by itself.

N+1 runs for N addresses, so the 10 cap means 8 or 9 per ticket, I kicked B directly so I don't know if rule A counts in the chain. No spaces after the commas in that test, with spaces add .trim().

Try it on one ticket, and if it misbehaves paste the audit log here?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-cloud

jira-service-management-cloud

jira-service-management

team-managed-projects