The Pool Dashboard is where service teams receiving tickets frequently will find many yet-to-be-assigned tickets. These unassigned tickets are can then be assigned to team members in a Firstfirst-Inin-Firstfirst-Out out manner. So, the ticket that has been in the queue for the longest time gets assigned first.
The manager or admin can straightaway assign pending tickets from the pool, and this process is independent of automated rotational assignments.
Why is Pool needed?
For example, let's consider a team that has with 2 members (A and B) and both have , each having an Individual Maxcount of 5. At the momentCurrently, both have 5 open tickets in their individual personal buckets. Consequently, and therefore, all the new incoming tickets will be held stored in the pool until one of them resolves/closes one or more some of their tickets. Now, suppose there is an incoming a high-priority ticket , this feature enables coming in. This functionality allows the admin to exercise use their judgement, discretion and assign the 6th 6th ticket to either A or B as they deem see fit. This manual assignment will also override the First-In-First-Out concept of ticket assignment.take precedence over the usual first-in-first-out approach for ticket assignments.
State of pool
When a ticket is in the "Open" state, it means that the scheduling condition has been met but there are not enough resources to address the issue or if the ticket has been waiting in the buffer for more than 15 minutes.
Transitioning to the "Buffering" state occurs when tickets meet the scheduling condition but do not satisfy advanced JQL rotation conditions. The issue will stay in this state for 15 minutes, with its status being checked every minute for ticket updates. If any changes occur and conditions are satisfied, the ticket will be assigned; otherwise, after 15 minutes, it moves into the pool.
Want to learn more about Buffer Zone ?
...