Moving Tickets between queues: best practise?

Hello,

I’m running a RT with two queues, Level 1 Support (L1) and Level 2
Support (L2). Ticktes are normally created in Level 1. The Users in
Level 1 (L1 Users) have access to both queues and reassign incoming
ticktes to the Users in Level 2 (L2 Users).

The L2 Users do not see L1, they shall not be distracted by the tickets
in Level 1.

Now, when L2 Users have finished their work, the tickets normally would
be closed. But our goal is that the L2 User has finished his work, he
sets the ticket to something like “done” and then the ticket is being
moved back to L1, where a L1 User reviews it and then finally closes it.

I think abaout different ways to do that, but none of my ideas is really
elegant and simple. So my question if there is any best practise for
doing so?

Thanks in advance for any idea, comment… Regards, Patrick

Hello,

I’m running a RT with two queues, Level 1 Support (L1) and Level 2
Support (L2). Ticktes are normally created in Level 1. The Users in
Level 1 (L1 Users) have access to both queues and reassign incoming
ticktes to the Users in Level 2 (L2 Users).

The L2 Users do not see L1, they shall not be distracted by the tickets
in Level 1.

Now, when L2 Users have finished their work, the tickets normally would
be closed. But our goal is that the L2 User has finished his work, he
sets the ticket to something like “done” and then the ticket is being
moved back to L1, where a L1 User reviews it and then finally closes it.

I think abaout different ways to do that, but none of my ideas is really
elegant and simple. So my question if there is any best practise for
doing so?

  1. Add a custom status of your choice using Lifecycles for the “L2 done”
    state [1]

  2. Write a custom scrip in the L2 queue where the condition is a status
    change to your custom status from #1. This condition can either be a
    short custom condition, or you can use RT::Condition::StatusChange from
    the dropdown with a short initialdata [2] file to insert your particular
    status condition into the database. The action of the scrip will be a
    short custom action that calls $self->TicketObj->SetQueue(“L1”).

  3. Create a dashboard or saved search for L1 users to see tickets in L1
    that are marked for review, so they can process the tickets and then
    resolve them.

[1] Customizing/Lifecycles - RT 4.0.25 Documentation - Best Practical
[2] Initialdata - RT 4.0.25 Documentation - Best Practical

That’s the basic idea. You can do this using a single status in a
single queue, and simply have the L1 team look in the L2 queue for that
status, or do the queue moving, or do the queue moving and switch
statuses upon moving back into L1 (either in your scrip or a lifecycle
transition map).