Automatic balanced load method - problem

[Artur Lemieszek]

Hello,

I am in the process of setting up automation that will check every 15 minutes for new tickets and whether they are unassigned. (1st screen)

The script in the Assign operation shows all tickets that are currently assigned to users but does not include new unassigned tickets -> it's connected with load balancing method.

And the question is – should it be this way? Or should the script be different? (2nd screen)

Even though I think I did everything correctly, it’s not working as I expected...

Example:
I created 8 test tickets for 4 people (I was expecting a result where each person gets 2 tickets), but instead, I got this:

• Person 1 – 4 tickets
• Person 2 – 3 tickets
• Person 3 – 1 ticket
• Person 4 – 0 tickets

Another attempt with 8 new tickets:

• Person 1 – no change in the number of tickets
• Person 2 – no change
• Person 3 – no change
• Person 4 – 8 tickets

So after creating 16 tickets, the distribution of tickets is as follows:

• Person 1 – 4 tickets
• Person 2 – 3 tickets
• Person 3 – 1 tickets
• Person 4 – 8 tickets

I have a feeling that either the load balancing method doesn’t work well when processing and assigning a specific number of tickets at a given moment, or maybe there’s something wrong with my automation 😆 Could u please help somehow?

[Bill Sheboy]

Hi @Artur Lemieszek -- Welcome to the Atlassian Community!

I hypothesize what happens is the Scheduled trigger processes the issues found with the JQL in parallel (for improved rule performance) and this creates a "racetrack condition" where it is unknown how many issues will be found assigned as the rule proceeds.

Although there is nothing in the trigger documentation to describe this behavior, the same thing happens for rule branches on more-than-one-thing.  The only way to confirm that for the Scheduled trigger would be to ask the Atlassian Support team: https://support.atlassian.com/contact/#/

For your scenario, one way to solve this is to assign the issues as soon as they are created (or another single-issue trigger, such as Issue Transitioned).  That will both reduce the scope of issue checking to one issue at a time and reduce some of the racetrack impacts:

• trigger: issue created
• action: re-fetch issue
• condition: issue is not assigned to anyone
• action: assign issue, with balanced workload

Kind regards,
Bill

[Artur Lemieszek]

Hi @Bill Sheboy, thanks for the answer ;)

The solution you proposed earlier was something I had already implemented, and yes, it works correctly because it processes one issue at a time.

However, handling one issue at a time also means that the rule is triggered once per issue. If I receive 1,000 issues per day, the rule will execute 1,000 times. My goal is to reduce the number of rule executions, which is why I came up with the idea of processing issues in batches every 15 minutes.

In the premium plan, there are 1,000 rule executions per user ;)

I think JIRA isn't quite ready for such automations yet :D

[Bill Sheboy]

I understand the rule usage limits concerns, although for your scenario it could encounter other limits for a batch processing approach:

• let's assume rules worked differently, and processed the scheduled trigger serially versus in parallel (which they apparently DO NOT :^)
• in that case, each issue would be checked and then updated, adding up to substantial processing time for that many issues in a single rule execution
• thus the total might exceed the processing time limit per 12 hours, the continuous processing limit, or the number of rules running at once limit (due to overlap with other rules hitting the engine)...any of which could halt all rules in the site from running for a day or more.

Perhaps a larger operations question (without knowing the size of your organization) is: why would 1000 issues be assigned in a single day to an apparent team size of 4 people (based on the rule image you show) when they could not possibly do that much workload?  Would it not be better to only assign work items when people have capacity to work on the next one?

[Artur Lemieszek]

It will be more than 4 people (about 25 people) ;)
I'm training with 4 people and 100 request per day for now to prepared for this situation ;)

The script works almost correctly, but it does not distribute the quantity properly as it should.

For example:

I created a different script that checks the status of issues marked as "In Progress" and "Waiting for Customer" simultaneously, running every 15 minutes. When the script starts, it detects newly added comments on both sides and moves the issues to the appropriate status. For example, if an agent adds a comment while the issue is "In Progress," the script changes its status to "Waiting for Customer." At the same time, it processes comments added by the customer and moves the issue from "Waiting for Customer" back to "In Progress."

This way, I saved a lot of rule executions! :)

I just want to automate almost everything ;)

[Bill Sheboy]

Sorry, I do not have better answers to solve both the reduced usage of rule executions and accurately balancing the worklog.  If rule usage was not a concern, switching to use the single issue transitioned trigger seems like it would help with load balancing.

Perhaps investigate the Atlassian Marketplace to determine if a vendor solved this problem in a way that would be cost effective for your organization (relative to changing Jira licensing to get more rule usage volume).