Queue Item facts and behavior

Today’s tip is on Queue Items. I’m not planning on reiterating what’s in the documentation, available HERE. You can read all about it yourself.

Instead, let’s look at a very specific use case.

Introduction

You can think of queue items as a container. When you add items like Cases or Activities to a Queue, you don’t add the item itself, but you create a queue item record that relates your item to the queue. As such, there is no separate security on the queue item itself, it is using the  inherited properties from the Queue. You can enable entities for Queues as needed, as seen on the creation of a new entity in the following screenshot.

As explained, a Queue Item record is created when an item is added to a Queue. It relates the item per se (a Case for example) to a specified Queue, as well as holding some other specific information about the item, like time it was added to the queue, last modified, etc.

The interesting thing is that the queue item is retained when moving an item from one queue to another. As such, when taking one item from one queue and assigning it to another queue, the same queue item record remains active, and it only updates the Queue reference.

You can observe this behavior by comparing an output of Queue Items exported to Excel with the item in Queue #1 and then after it’s been moved into Queue #2, as seen in the screenshot below. The Queue Item record retains the same internal ID.

Note that the Queue Item ID is not visible or available to select in Advanced Find, you have to export to Excel with the full columns set.

And for clean-up, a queue item record is removed when selecting Remove on the ribbon. But as long as an item is related to a queue, a queue item valid record is kept in the system.

Why is it important

When putting a process in place, triggers are affected by this queue item behavior. On adding a new item to a queue, a brand new queue item is created, so you can trigger on the create event. Let’s say a case was generated automatically in the system, and put into a service queue. Now, your process can be triggered on create of a queue item.

But when an item is simply moved from one queue to another, the existing queue item record remains in place, and only the reference to the queue is updated. This does not trigger a queue item create event any more, so when triggering on this scenario, you have to look at the change on the Queue reference field of the Queue Item.

In conclusion, when handling a scenario where you want to trigger an action when an item enters a specific queue, you have to look at both the queue item created action, as well as the queue item –> queue field change and compare it against the queue you are trying to monitor.

Hopefully this will save you a little time when figuring out why a process is triggered when an item enter a queue in some instances, but not in others.

Was this useful? Leave a note below!