Maximum number of queues in RT

Hi,

Since discovering RT we have fallen in love and ended up going queue crazy. We currently have 38 active queues in our 4.4.4 implementation and we have loads more on our roadmap. I estimate that we may end up with more than 60 queues so I am just a little concerned about the impact that may have on the overall health of RT and have a couple questions:

Is there an upper limit to the amount of queues you can have in RT?
Will this high number of queues impact RT’s performance in any way?

luhLloyd

We have way more than 60 queues in some of our RT instances (around a 130 in the main service desk oe for example). You’ll be fine. :slight_smile:

We have about 4000 Queues without any problem :slight_smile:

Well then, it’s Queue happy days for us! :grinning:

What do you use that many queues for and how do you manage them? Eg keeping the scrips all correct for each queue?

We create a Queue for every service of our customers (automatically, based on the contract). Some customers have more than ten Queues, others only one. We need this because different workers/subcontractors work on every service and that is how we can fine tune the permissions, notifications, etc. We did some modifications on the admin side to ease the use of these many Queues but nothing too special.

We have several different streams of client tickets (calls and correspondence) which we have to report on connected to contracted SLAs for our contact centres. Then we have all our internal company queues like helpdesk, plus with our entire workforce being constantly remote we are creating a lot of task tracking and implementation queues.

We have a few basic types:

CRM Logger queues for call centre calls
External Customer facing query correspondence queues
External Customer facing implementation queues
Internal Company Resource queue, eg IT helpdesk or the incident queues
Internal Department Task queue -SOPs, processes etc

Then we also got jiggy with a few specialised queues like our call centre QA queues and some queues created just for dashboards like our RT Roadmap for Queue Rollout and so on.

Yeah, we love RT!

1 Like

Oh, in all that I didn’t answer your question :grinning:

By having different types of queues we have just built a model of what scrips work and how to configure all the templates and then its a case of careful replication whenever you rollout a new instance of that queue type.

To go with that is the permissions model for certain scrips like auto assign (we’re allergic to unowned tickets on customer facing queues) that allows the department to add and remove members from the auto assign group when members are on leave.