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

[Tiemen Blankert]

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 solution]

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

[Tiemen Blankert]

Thanks! That clears it up. Do you know where i can find any documentation on those contexts? I can't seem to find it myself.

I wonder why they made it this way, isn't it reasonable to think that on complete sprint trigger sometimes also needs all the issue information/context? Im doing it to generate release notes and it needs to run when a team closes a sprint.

Anyway I found a workaround myself: I created a variable with this smartvalue :
"{{#lookupIssues}}

Issue: {{key}}
Summary: {{summary}}
Attachments: {{attachments}}
--- {{/}}"

and then passed the variable in the rovo prompt.

Thanks anyway!