Why does {{lookupIssues}} behave differently between triggers?

Question

While in the process of building an automation that should do something with issues on sprint complete, I used a manual trigger to test the rule so I don't constantly have to make/reopen dummy sprints. When I was done I switched the trigger to on sprint complete and tested it. To my surprise the {{lookupIssues}} now behaved different:

I ask a rovo agent to go through the attachments in {{lookupIssues}} and write down the filenames in a specific format(along with generated texts which is used later in a web request). This works fine when doing it the manual trigger way. However, when I switched to the on sprint complete trigger, the rovo agent couldn't see the attachments in {{lookupIssues}}. I find this very weird and don't understand what the difference is.

If I log the {{lookupIssues.first.attachments}} I can see the attachmentbeans in both versions. I know that when referring to {{lookupIssues}} in bulk, one cannot see the full attachment beans but a reduced version which contains at least the filenames. I built my whole automation on the assumption that lookup work items works the same in both cases and now I probably have to rethink and rewrite a lot which is very frustrating.

anybody knows why this happens?

anybody knows a workaround?

Hari Krishna · Accepted Answer

Hi @Tiemen Blankert ,

This difference is expected and comes down to how automation context is built for different triggers.

When you use a Manual trigger, Jira executes the rule in a full issue context, so {{lookupIssues}} contains richer data and downstream actions (like Rovo agents) can access attachment metadata as expected.

When the trigger is Sprint completed, the rule runs in a sprint-level context, not an issue-level one. In this context:

{{lookupIssues}} still returns issues

Attachments are available only as limited beans

Actions that require full attachment context (like Rovo agents reading filenames/content) may not be able to access them

That’s why:

Logging {{lookupIssues.first.attachments}} works (basic data exists)

But the Rovo agent cannot “see” or process the attachments

Workarounds

Add a branch: For each issue in lookupIssues and run the Rovo agent inside that branch (this restores issue-level context)

Or trigger a secondary rule (issue-based) from the sprint rule and do the attachment processing there

Avoid relying on bulk {{lookupIssues}} attachment access when using sprint-based triggers

Bill Sheboy · Accepted Answer

Hi @Tiemen Blankert

First thing, when I test rules like this I use a Scheduled Trigger (with or without JQL) and Created Variables to supply data, only writing results to the audit log rather than making work item changes.  This ensures there are no side-effects and often has no "cost" for monthly usage limits.  When the rule works as expected, then switch to your desired trigger and update the rule components as needed.

Back to your rule, there are two possible causes for the symptom you observed:

(a) The {{issue.sprint}} smart value is a list, and thus the JQL expression sprint = {{issue.sprint.id}} could be comparing a field to a list-as-an-array, causing unexpected results.

(b) Some smart values are only loaded just-in-time when used, potentially leading to race-track timing problems in some rule actions.  I have observed this with the attachments, subtasks, and issuelinks smart values.  Depending upon the rule scenario, a couple of workarounds are to first capture the data in created variables (forcing full evaluation) or to use the long-format iterators to give logic time to load the information.

Kind regards,
Bill