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