[rt-users] Best practices: Queues vs. Custom fields

[Nathan Oyler]

> Howdy.
> 
> We're beginning our test implementation of RT, and we currently plan
to
> have several queues for different types of requests: development,
> repairs (one-time), maintenance (recurring, but not regularly),
supplies
> (printer toner, etc.).  Additionally, the powers that be want the
> ability to generate reports based on departments (e.g., average time
to
> resolve tickets coming from Accounting).  For this, I propose adding a
> Custom Field to tickets designating the requestor's department.
> 
> Would it make more sense to have Queues by department and handle
request
> type differently?
> 

I choose to use queue's by department, and then issues on to that.

So Development::QA::Deployment
Or Development::Research::X

Or Services::Client::$client
Or Services::Internal::AccountManagers

Works well for me, ymmv.


> Is there a recommended "best practice"?
> 
> On a related note, when a requestor creates a ticket via e-mail, could
> the proposed department field be auto-populated based on the
requestor's
> address, or should the department field instead be part of the User
> object?
> 

If you are using LDAP, you should already have the department as a part
of their id in active directory. That can be filled in automatically to
the users object.

That being said, you could still auto-populate a ticket's custom field
based on the requestor address. What do you do with CC's? Add those as
well?

A Multiple select department list?

In my mind, having them separated by queues is easier. I find that
things like, specific custom fields are easily to deploy like that. I
can set permissions very easily by locking off views between
departments, and units.

Give managers an amount of control, view over their units tickets.

Do individual group reports based on each member of a group, which has
permissions to the queue. So Manager X in Development has a queue for
his team. Each member is in a group for permissions to that queue (and
subsequently any shared queues)

Can generate reports based on tickets open, for each member of group.
Which ends up being their team.

You may be able to do all of this without doing departmental queues.
Just what works for me.