Jira Automation + Rovo Agent: JQL Limited to 50 Issues — How to Process All Results?

[Maor Levinas]

Hi all,

I’m using Jira Cloud Automation with a scheduled rule that passes a JQL query into a Rovo AI agent. The agent analyzes each issue and writes an AI‑generated summary to a custom field.

The problem: when the agent executes the JQL, it consistently returns only 50 issues, even when the JQL matches many more. The execution log explicitly says it’s “returning 50 issues”.

As a result, only the first 50 issues are processed on each run.

What I’m trying to understand

• Is the 50‑issue limit a hard limit of Rovo agents, or can it be configured?
• Is there a recommended way to batch, paginate, or loop agent execution in Jira Automation?
• What patterns are people using to ensure all issues from a JQL are eventually processed?

Context:

• Jira Cloud
• Scheduled automation
• AI output written to a custom field
• JQL can return hundreds of issues

Any guidance, documented limits, or architectural patterns would be appreciated.

Thanks

[Bill Sheboy]

Hi @Maor Levinas 

How many work items were you expecting to process?

A workaround would be to moving the primary JQL to the Scheduled Trigger and eliminate the rule branching, potentially allowing up to 999 work items...subject to your license level and service limits for automation:

https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

Kind regards,
Bill

[Maor Levinas]

Hi @Bill Sheboy 

Thank you for your answer and for pointing out the option of moving the JQL to the Scheduled Trigger. I expect hundreds of work items.

In my case, the main constraint is cost: each call to the Rovo agent consumes credits. If I move the JQL to the trigger and run the rule per issue, that would significantly increase the number of agent calls. My goal is precisely to minimize the number of calls, ideally by keeping the branching logic and having the agent reason over a batch of issues in a single invocation.

That’s why I’m trying to understand whether the ~50 issues behavior is a hard limit or a prompt/automation constraint, and how best to batch while still keeping the number of agent calls low.

Thanks again for taking the time to respond.

[Bill Sheboy]

@Maor Levinas with hundreds of work items to process, you may run into various service limits, for both automation and per user limits for Rovo:

• https://support.atlassian.com/cloud-automation/docs/automation-service-limits/
• https://support.atlassian.com/rovo/docs/rovo-usage-limits/

As you appear to be on a paid license level, you could work with your Jira Product Admin and submit a ticket to Atlassian Support.  They will be able able to review internal logging as to what is happening with the rule processing.

https://support.atlassian.com/contact/#/

When you hear back from them, please post what you learn to benefit the community.  Thanks!

[Rebekka Heilmann _viadee_]

@Maor Levinas have you tried telling the Agent to use the JQL pagination to create batches and run whatever you are doing on each of those batches?

Rovo can now run multiple actions at the same time (e.g. multiple searches) if being told to.

[Maor Levinas]

Thanks @Rebekka Heilmann _viadee_  for your suggestion.

I'll give it a try

[Maor Levinas]

Hi @Bill Sheboy 

Here is the answer from Support.

Current Limitation and Tracking
You are correct that the Rovo Agent currently processes only up to 50 issues when a JQL query is passed in this way. Although this appears to be a hard limit, it has not yet been officially documented. We have an open feature request to address this behaviour, which you can track here: ROVO-396 - ROVO Agents when use JQL results, show incorrect results. Please feel free to watch or vote on this request for future updates.

Bug Prioritisation and Policy
Atlassian prioritises bugs based on their impact and frequency. You can learn more about our approach in our Implementation of New Features Policy.

Addressing Your Questions:

50-Issue Limit: At this time, the 50-issue limit is a constraint of the Rovo Agent, though not officially documented. We are working to clarify this in our documentation.
Configurable Limit: Currently, this limit is not configurable, regardless of plan type.
Reason for the Limit: The behavior is likely due to internal constraints such as prompt size or processing limits, but we are still investigating the exact mechanism.
Credit Consumption: Since this is a current limitation, we can't guarantee how credit consumption might change if the limit is increased or removed in the future. We'll update the feature request with any changes that could impact usage or billing.
Workarounds and Best Practices

Given the current limitation, here are some practical approaches:

Batch Processing via Multiple Automation Runs:
To process more than 50 issues, consider splitting your JQL into multiple queries using additional conditions (e.g., by issue key range, creation date, or status) and triggering the automation separately for each batch. This allows you to process larger sets of issues while staying within the per-invocation limit.
Multi-Agent Workflow:
If your workflow allows, you can use multiple agents or automation rules, each responsible for a subset of issues. Ensure each agent’s scope is clearly defined to avoid overlap or missed issues.
JQL Optimisation:
Saving your JQL as filters and referencing those in your automation can sometimes help streamline processing. However, the 50-issue limit will still apply per agent invocation.
Minimising Credit Consumption:
To avoid running the rule once per issue, batching is the best approach. While the current limit is 50, batching by logical groups (e.g., by project, assignee, or time window) can help minimise the number of agent calls.
 

Adding this to the prompt enabled me to fetch more results, but I'm not sure this is very robust.

When executing any JQL query:
- Set the maxResults parameter to 150
- The agent must never assume that the first response contains all results.
- The agent must always paginate until all issues have been retrieved.

I will probably stick to the 50 limit and set up an automation that call itself

[Bill Sheboy]

Thanks for posting the support response, @Maor Levinas 

And...based on how they describe the processing, I hypothesize the actual limit is "up to 50, but perhaps fewer when used inside of a branch".  The reason is another undocumented limit on the amount of processing storage feeding a branch, such as when a rule already loaded a Lookup Work Items, Lookup Objects, or Send Web Request action.  These can lead to an out-of-memory condition, and perhaps would then also limit the agent processing.  Only experimentation and the Atlassian development team could confirm this hypothesis.

To learn more about that branching problem, please look here:

https://community.atlassian.com/forums/Automation-articles/Automation-concepts-Branching-memory-resource-limit-can-halt/ba-p/3036528

[Don Hames]

Hi @Maor Levinas

I do not think it is a hard limit on the automation or on the Agent, but Agent prompts can only handle a certain length before truncating. Can you try sending the JQL results to the Agent in batches? Yes, it will require multiple invocations to the Agent, but it may provide insight into how much you can pass to the Agent for processing at a time.

Another idea is to pass the JQL query to the Agent for processing. JQL queries are always preferable to long text entries.

I have successfully sent users or issues to an Agent in a CVS file, and it seems to process them in larger batches.

I hope this helps!

[Maor Levinas]

Hi @Don Hames  

Thank you for your reply.

This is actually what I’m already doing: I’m passing the JQL query itself to the Agent rather than a long list of issues. Despite that, the Agent still stops after processing 50 issues, which is why I suspect a truncation or internal handling limit on the Agent side.

If that 50-issue limit cannot be configured or increased, then I’m effectively forced to iterate. What I’m trying to determine is the best iteration strategy to process groups of 50 issues while minimizing cost and credit consumption (i.e. avoiding too many Agent invocations).

So the open question for me is really: what is the most cost-efficient pattern to paginate or batch those 50-issue chunks when using a Rovo Agent?

Thanks again for taking the time to share your experience.