Custom fields best practices

Hello,
I am trying to find some best practices information on custom fields and
where they are applied. I currently have RT 3.8.2 running with many custom
fields associated with “tickets.” Can someone explain to me what the
reasoning would be to associate them with say “queues, users, global, ticket
transactions” and the like? I wasn’t really able to dig up any info on
this. Maybe someone could point me in the right direction.

Thanks,
Kyle McKinley
123net
View this message in context: http://old.nabble.com/custom-fields-best-practices-tp26716645p26716645.html

global
Globals are not a type unto themselves, but a scope for the other types.
This seems most useful for tickets where you want a CF to be available
for most if not all of your queues (and if not all, it’s presence is not
a problem in the others) e.g; a Tags field.

The ticket and transaction CFs can be queue-specific or global.

queues
No idea.

ticket
Non-transaction information e.g; custom status, reference ID for an
external system (Nagios, purchase order)

transactions
Track your staff’s stress on a per interaction basis, or stash some value
for a scrip to operate on, etc.

users
Say you want to store a fax number as well as the already supported
pager number, or the person’s birthday, SSN (shame on you), etc.

global
Globals are not a type unto themselves, but a scope for the other types.
This seems most useful for tickets where you want a CF to be available
for most if not all of your queues (and if not all, it’s presence is not
a problem in the others) e.g; a Tags field.

The ticket and transaction CFs can be queue-specific or global.

queues
No idea.

You can set some customfields on queues to add informations on them.
Then you can modify the RT UI to display those informations or you can
use this information in your scrips (if ticket fall in a queue with cf X
= value Y, then do something).
Can be very usefull in some circumstances.
If you want to be able to find all tickets that are in a queue with CF x
= value Y, you cannot do this with the RT search system, so one solution
is to add also a customfield on tickets named x, and create a scrip that
fill this customfield with value of corresponding queue customfield when
a ticket is created or moved to this queue.