Branch on AQL issue

[Adrian Wiórek]

Environment: Jira Service Management Cloud, Global Automation (Branch on AQL), Assets/CMDB

Context: I have a CMDB object of type MPK (cost center) with a reference attribute Manager (type: Object, multi-value, reference type "Manager"), which can contain one or several managers (User objects). For each manager in this attribute I want to add them to the Request participants field on a JSM issue.

Problem 1 — multi-value attribute as a smart value is not iterable. When the MPK has a single manager, lookupObjects.Manager.Label returns a clean string (e.g. John Smith) and everything works. When the MPK has two managers, the same value returns a string formatted as [Jane Smith, John Smith] (square brackets, comma-separated). I tried the following methods to split this value into individual elements, none of which worked: lookupObjects.Manager.Label.0 returns empty; lookupObjects.Manager.0.Label returns empty; lookupObjects.Manager.Label.get(0) returns the whole value (Jane Smith, John Smith), not the first element; lookupObjects.Manager.Label.split(", ").get(0) returns empty with no error; lookupObjects.Manager.Label.replace("[", "").get(0) returns empty. It seems that Manager.Label on a multi-value attribute is neither a true String (text methods split and replace don't work) nor a true iterable list (get(n) does not index into it).

Problem 2 — Branch on AQL with inR() doesn't work in the context of the automation action. As a workaround, I tried reversing the query and using an inbound reference, so that Branch on AQL would directly return the manager objects, each as a separate branch iteration: object HAVING inR(ObjectType = MPK AND Name = "Z118", "Manager"). This query works correctly and returns 2 objects (managers) when I test it manually in the AQL search bar in Assets, in the Advanced AQL search tab. However, when I enter exactly the same query, both with a variable mpkName and with the value hardcoded as Z118, as the Query in the Create branches with AQL action in a Global Automation rule, the branch only runs once, and lookupObjects inside that single iteration is the MPK object, the same one we were operating on before the branch, not a manager. Confirmed via audit log with an extra Log action showing lookupObjects.key = CMDB-5982, Label = Z118, size = 1, meaning it's the exact same MPK, not a manager.

Questions for the community: Is there a documented, working syntax for iterating over a multi-value reference attribute from Assets in smart values, besides the Lookup Objects action with a plain AQL query against an object type? Is inR() even supported inside the Branch on AQL action, or is this a limitation specific to that action, even though it works in a regular Assets search? Is there any other mechanism, besides REST API and Send web request, to split a multi-reference attribute into separate branch iterations without nesting branches, which is officially unsupported?

Version: Jira Service Management Cloud (Premium), Global Automation, tested June 2026.

[Marc -Devoteam- · Accepted solution]

Hi @Adrian Wiórek 

For problem 1 see if {{LookupObjects.Manager.flatten()}} will sort this problem.

[Adrian Wiórek · Accepted solution]

Here's the solution I found, for anyone who runs into the same issue:

Problem 1 (multi-value attribute as a smart value) — confirmed there's no way to split or index Manager.Label directly when it contains multiple references. However, .flatten() does work, it turns the attribute into a properly iterable list of objects:

{{lookupObjects.Manager.flatten().get(0).Key}}
{{lookupObjects.Manager.flatten().get(1).Key}}
{{lookupObjects.Manager.flatten().get(2).Key}}

This returns the object Key (e.g. CMDB-3765) for each manager individually. From there, a separate Lookup Objects action per key, using the Key attribute (not objectKey, which doesn't exist as an AQL attribute):

Key = "{{managerKeyOne}}"

lets you pull the accountId via {{lookupObjects.Użytkownik Jira.key}} (or whatever your Jira user reference attribute is called) for each manager separately.

Problem 2 (Branch on AQL with inR) — turned out to be a dead end. The query worked perfectly when tested manually in Assets search, but inside the Create branches with AQL action it consistently returned the parent object instead of iterating over the referenced objects, with no error. Abandoned this approach entirely.

Final working solution — no branching needed. For up to N possible managers (3 in my case), I create N variables using .flatten().get(n).Key, do N separate Lookup Objects plus Create variable steps to resolve each Key into an accountId, then before each Edit issue action add a Condition checking that the corresponding accountId variable is not empty. This prevents the rule from failing when a given MPK has fewer than N managers, empty slots are simply skipped instead of throwing Specify a valid value for customfield_X.

Tested and confirmed working for 1, 2, and 3 managers per cost center.

Thanks @Marc -Devoteam-  for the .flatten() pointer, that's what unblocked Problem 1. This also ended up solving Problem 2, since instead of trying to write the whole list of users into the Request participants field in a single update, each user is added through its own separate Edit issue action using the add operation, which sidesteps the field's limitation around writing multiple values at once.