Staff can create custom queues that replicate the processes of the standard default queues. Custom queues are created and edited under the Queues tab in the Customization Manager. There, custom queues are distinguished from default queues by the + sign icon to the left of the queue.
Using Custom Status Queues
You can create and use custom status queues to customize your workflow. For example, if you wanted to have more queues to describe In Item Retrieval, you could create custom queues that would behave the same as In Item Retrieval. You could call them something like Pulling From 1st Floor Stacks, Pulling From 2nd Floor Stacks, etc. Custom queues can be used when you are manually routing requests in the workflow process and when moving requests via routing rules.
Example Custom Queue: Awaiting Faculty Request Processing
Awaiting Faculty Request Processing can be created using the State Awaiting Request Processing and its corresponding State Code. The Awaiting Faculty Request Processing queue is incorporated into a routing rule that will automatically move any requests from a faculty user to that queue.
Example Custom Queue: Pulling From First Floor Stacks
A second custom queue, Pulling From First Floor Stacks, was created from the State In Item Retrieval. When routing the request from Awaiting Faculty Request Processing, this custom queue is displayed as a routing option because it mimics the In Item Retrieval queue.
Displaying Custom Queues on the Aeon Home Page
If you would like to distinguish your custom queues from the defaultAeonqueues, you can create a category to display thecustomqueues separately in the Requests and Activities Groups. For instance, you can create a category called Custom Request Queues to hold thecustom queues containing requests separately from your default queues. When a request is moved to one of your custom queues, it will automatically display under the category Custom Request Queues. When there are no requests within the queues under your category, the category will not display. When requests are added to those queues the category will re-display on the Client interface. Customizations are automatically saved for individual users, and can also be saved to a file, shared and adapted by other users.
Custom Status Queues and Request Limits
If a user has a specified request limit, requests in custom queues based on default active queues are counted against the user's request limit.
See Configuring Default Queues and Custom Queues for detailed information about renaming default and custom queues.
While it is possible to change the names of default queues, it is not recommended.
When you change the name of a default queue, the display name in the State column of the Customization Manager automatically changes to match the new queue name. In addition, the State of any custom queues automatically changes to match the new State of the default queue from which it was created. At that point, it will no longer be obvious what State (that is, workflow process) the default queue originally used, or what default State a custom queue is using. Again, you will not be able to determine the original default workflow process carried out by the queue by looking at the State.
When you change the name of a default queue, be aware that you are not just changing the display name as it is shown in the client and web pages. Changing the name of a default queue also changes the QueueName in the database. So, for example, if you change Awaiting Request Processing to "New Remote Request", the QueueName field and State column will also change from Awaiting Request Processing to New Remote Request. The State Code of default queues does not change, so you can use the State Code to identify the intended workflow process for the default queue, but without the State description you won't know what process the State Code is referencing. It is possible to use the Internal Code field as explained in The Queues Table data from the Queues table to a file to locate the original State information, if necessary.