Matt,
The performance in RT seems to drop off when the are a lot of users
with a lot of permissions to the tickets in a queue. We have over 75
queues and restrict the ability to update tickets to a select few
(specific groups for specific queues) and we have pretty good performance.
We have a lot of software support so we prefix the name of the queue
with the organization the software is supporting. For example, all of
out financial software is broken down into individual queues for each
package (like GL, AP, AR) but with the prf-fix for the organization.
i.e. FS-GL, FS-AP, FS-AR where “FS” is for “Financial Services”. It
makes it easier to find them on a page or menu. We also limit how many
queues a person sees by limiting such rights as “SeeQueue”,
“ShowTicket”, “CreateTicket”, ModifyTicket", “OwnTicket”, etc. to the
specific groups for those queues. It cuts down on them having to page
thru 75 different queues AND it speeds up page loading and searches.
We also have a general “Bucket” or “Request” queue to act as a review
and approval queue for about 20 queues that are related. This keeps
requestors from dumping a bunch of tickets into a queue when the support
team isn’t ready to work on them AND, more importantly, it allows those
group members that review the requests in the “bucket” queue to evaluate
and set the priorities. After prioritization, they are either rejected
or approved for work, at wich time they are moved to the appropriate
“support” queue. This keeps things moving along evenly and without alot
of melodrama and trauma.
We highly recommend RT, but if your session is going to be a busy one
with more than 10 queues, we suggest that you create “User” groups for
those that only need to send/create requests (in other words, these
users are not to be working on the tickets, just getting results) and
“Support” groups for those users that will be working on those requests.
We further recommend you name the groups such that they can be
identified by the queue they create/own/resolve tickets in and the type
of function the perform. This will nip a lot of confusion in the bud.
Also, spend ALOT of time learning about the granting of privileges and
how they relate/cascade for both tickets AND Custom Fields. Hope this helps.
Kenn
LBNLOn 4/23/2008 2:26 PM, Matt Zagrabelny wrote:
Greetings,
I am in the early throws of setting up and configuring RT for our
university. I have a question about the granularity with which to create
queues.
First off, is there a performance or otherwise soft or hard limit on the
number of queues that are created? Or is the “only” downside of creating
many queues the fact that you now need to sift through the multitude of
queues to find the one you are interested in?
Secondly, is there namespaces for queues? That is, some way of
organizing queues into logical groups?
Lastly, I am wondering if anyone can confirm the track that I am going
down or otherwise point me in another direction.
I am thinking that we will have somewhere between 4 and 10 “top level”
queues at our university.
Some off the top of my head are:
- help desk
- phone network requests
- maintenance requests
- projects
Underneath those headings there could be queues such as the following:
-
help desk
|
- systems team
- desktop team
- maintenance team
- phone net team
.
.
.
-
phone net requests
-
maintenance requests
-
projects
|
.
.
.
- systems project N
- classroom project 1
.
.
.
- classroom project N
- other project
- etc.
I am looking at creating too many queues? What have others done that are
trying to use RT as the single ticketing system for many different
facets of a large organization?
Thanks,
-Matt Zagrabelny
The rt-users Archives
Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com
Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com