The Aeon Client is installed with a set of default status queues that requests move through in the workflow process. Staff can create custom status queues based on these default queues to further customize your workflow. Staff can manually route requests through the workflow queues or create routing rules to automatically route them. In addition, staff can organize and categorize queues in the Requests and Activities group in a way that works best for them.
Aeon is designed to help you fill your patron's requests for special collections and archives items with full control and ease. The default status queues assist you in managing every step of each transaction from start to finish. You can access requests from queues in the Requests and Activities groups on the Home Page. The Queues table, found in the Aeon Customization Manager under the Queues tab, displays each active default status queue by Name along with the corresponding Web Display Name, State, State Code, and Queue Type. To access this table in the Customization Manager, click the Queues tab at the top of the Customization Manager screen. The Queues table is also used to create custom queues for your workflow processes. Shown in the table below are the default status queues and the queue type and description of the workflow process for each queue. To view a table of the default status queues with the State, State Code, and Internal Code as shown in the Queues table, and a table describing the fields in the Queues table.
Aeon Default Status Queues
The table below lists the current default status queues and the queue type (either Transaction or Photoduplication) along with an explanation of the queue's function in the workflow process.
Transaction Queues
| Awaiting Activity Processing | Holds requests submitted for an Activity. |
|---|---|
| Awaiting Future Request Processing |
Holds requests to be filled at a later date. Determined by the FutureRoutingDays key. |
| Awaiting Item Reshelving | Holds requests for items that are ready to be reshelved or returned to archives. |
| Awaiting Request Processing | Holds requests submitted and approved by the researcher. |
| Awaiting Staff Request Processing* | Holds requests submitted by staff users. |
| Awaiting User Review | Holds requests held for review by the researcher. |
| Canceled by Staff | Holds requests that have been canceled by Special Collections staff. |
| Canceled by User | Holds requests that have been canceled by the researcher. |
| Cloned From Request | Transitory Status. Denotes when a request has been cloned from another request. |
| Cloned To Request | Transitory Status. Denotes when a request has been cloned to a new request. |
| Imported From Legacy System | System Status. Denotes when a request has been migrated from another system. |
| In Cataloging* | Holds requests for items that have been checked out for cataloging. |
| In Conservation/Preservation* | Holds requests for items that have been checked out for conservation/preservation. |
| In Item Retrieval | Holds requests for items that are being retrieved from Special Collections shelves and archives. |
| In Photoduplication | Holds photoduplication requests in the process of being scanned or copied. |
| In Processing* | Holds requests for items that have been checked out for processing. |
| Item Checked Out | Holds requests for items that have been checked out to the researcher. |
| Item Checked Out to Activity | Holds requests for items that have been checked out for an Activity. |
| Item Checked Out to Staff* | Holds requests for items that have been checked out to a staff member. |
| Item on Hold | Holds items that have been placed on hold by Special Collections staff. |
| Item on Hold for Activity | Holds items that have been placed on hold for an Activity by Special Collections staff. |
| Item on Hold for Staff* | Holds items that have been placed on hold for staff members. |
| Item Reshelved | Holds requests for items that have been returned to Special Collections shelves and archives. |
| New Reading Room Request* | Holds requests that have been submitted by researchers who are currently signed into a reading room. |
| Remove from Hold | Holds items that have been removed by a researcher from the Item on Hold or Item on Hold for Activity statuses. |
| Request Finished | Holds requests that have been completed. |
| Request in Processing | Transitory Status. Denotes when a request in Awaiting Request Processing is opened. Keeps other staff users from opening the same request. |
| Request Merged | Transitory Status. Denotes when a request has been merged into a new request. |
| Re-Submitted by User | Transitory Status. Denotes when a request has been canceled and resubmitted by the researcher. |
| Submitted by Staff | Transitory Status. Denotes when a request is submitted by Special Collections staff from the Aeon client. |
| Submitted by User | Transitory Status when denoting a transaction request submitted by the researcher from the web interface. May also indicate a copy request with an estimate that has not yet been approved by the researcher. |
| Web Request Created | Transitory Status. Records the request's entry in the database Transaction table. It is not visible in the History or Tracking panels. |
*Added in Aeon v5.2
Photoduplication Queues
| Awaiting Item Delivery | Holds photoduplication requests that are ready to be sent to the researcher. |
|---|---|
| Awaiting Order Approval | Holds requests that are waiting for researcher approval of invoice and costs. |
| Awaiting Order Billing/Awaiting Order Payment |
Holds requests awaiting invoice payment. Note: The default name of this queue was changed from Awaiting Order Billing to Awaiting Order Payment for new Aeon installations in Aeon 5.2.
|
| Awaiting Order Processing | Holds photoduplication requests submitted and approved by the researcher. |
| Awaiting Order Submittal | Holds photoduplication requests awaiting approval by the researcher. |
| Item Delivered | Holds photoduplication requests that have been sent to the researcher. |
| Order Cancelled by Staff | Holds photoduplication requests that have been canceled by staff. |
| Order Cancelled by User | Holds photoduplication requests that have been canceled by the researcher. |
| Order Finished | Holds photoduplication requests that have been completed. |
| Order Merged | Holds photoduplication requests that have been merged. |
Transitory Queues
Note that some of the default queues, such as Cloned from Request and Request in Processing, are transitory queues. Requests move through transitory queues as part of the workflow process, but these queues do not hold the requests for processing and are not visible in the Requests or Activities groups. These queues also do not display to users in the web interface. They are primarily used as a means of consistency in tracking requests through the workflow process and can be viewed in the History and Tracking panels of the Request form. One exception to this rule is the Submitted by User queue. It is a transitory queue when it denotes a transaction request submitted by the researcher from the web interface, but it may also indicate a copy request with an estimate that has not yet been approved by the researcher, and it will be visible on the web.
Web Request Created Queue
This is a transitory status assigned to each request when it is initially created that records the request's entry in the database Transaction table. It is not visible in the History or Tracking panes and requests should not remain in this status after they are created.
The Imported From Legacy System Queue
The Imported From Legacy System queue is available to use when you are migrating data from another system. This default queue can be used in routing rules and when creating custom queues. It is not visible in the Requests or Activities groups and does not display to users in the web interface though Requests at this status can be searched in the Client using the custom search feature. The queue does display in the History and Tracking panels of the Request form.
Renaming Queues
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.