Automated Request Manager - Example Use Cases for Processing Direct Requests Using the ARMMatchField Key

Print Friendly and PDF Follow

The release of ILLiad Connection Manager 9.2.4 implemented enhanced functionality to the process for direct requests sent from ILLiad to the OCLC Automated Request Manager (ARM), including a new ARMMatchField customization key that can be used to configure more granular ARM automation matches between OCLC and ILLiad. This article details several example use cases to demonstrate how you can take advantage of the new functionality to enhance your direct request workflows.

For detailed information on configuring the ARMMatchField customization key and its associated workflow, see Automated Request Manager - Enhancing ARM Workflows Using the ARMMatchField Customization Key. For an overview of the default ARM workflow between OCLC and ILLiad see Automated Request Manager - Configuring ILLiad and OCLC Resource Sharing Settings.

Use Case #1: Apply a Specific ARM Automation to Certain ILLiad Requests

Overview: Using the ARMMatchField key, you can send certain requests through a custom queue in ILLiad in order to apply a specific ARM automation to the request in OCLC.

Example explanation: If your ARMMatchField customization key in the ILLiad Customization Manager is set to Patron Notes (or any other match field) and your ILLiad request is routed (manually or automatically using a routing rule) into a custom queue you have configured named Awaiting LVIS ARM Sending, then the Connection Manager will insert the value LVIS into the Patron Notes field on the OCLC request that is created when the ILLiad request is sent to ARM. You can then configure an ARM automation in your OCLC settings that will match on all requests with the value LVIS in the Patron Notes field and apply specific automation actions to handle those requests.

Use Case #2: Review Lending String Added by ARM Before Sending Request to Lenders

Overview: The lending string is now exposed in the history table of the ILLiad Client request form after a request is processed by ARM. Additionally, requests routed to review by ARM will now send the request to the new Awaiting ARM Manual Review queue in ILLiad instead of the Awaiting Request Processing queue. This gives you the option to set up an ARM automation using the Route Request to Review action to send requests back to the manual review queue in ILLiad so that you can review the lender string to better understand potential suppliers as well as provide a better understanding of how ARM works when you’re first implementing these automations. You may also at this time determine if you want to send this request out or even purchase the item.

Example explanation: You can use the ARMMatchField key and a custom ARM sending queue in ILLiad if you would like to only route certain requests to the review queue in ILLiad in order to manually review the lending string before sending the request. For example, if following the example above, you sent the request to ARM using the Awaiting LVIS ARM Sending custom queue, you can configure the corresponding ARM automation for these requests to route the request to review. When ARM applies this automation and routes the request back to ILLiad, ILLiad will see the LVIS value in field specified by the ARMMatchField key on the OCLC request and route it to a special review queue called Awaiting LVIS ARM Manual Review. This way you can ensure that all requests sent through the Awaiting LVIS ARM Sending queue are returned to the Awaiting LVIS ARM Manual Review queue in ILLiad for manual review.

Use Case #3: Fill the Request Through Other Sources After ARM Processing or Resubmit the Request Back Through ARM

Overview: When a request that has initially been sent to ARM using a custom Awaiting {ARMMATCH} ARM Sending queue is routed to the Awaiting {ARMMATCH} ARM Manual Review queue in ILLiad by ARM, either because the corresponding ARM automation for those requests is set to route the request to review or because that request cannot be filled by the lenders, it can subsequently be sent to other queues in ILLiad for processing or resubmitted into ARM using the default direct request sending queue Awaiting ARM Sending to check your other custom holdings groups and apply different ARM automations.

Example explanation: If you initially sent a request to ARM using a custom Awaiting LVIS ARM Sending queue and the corresponding ARM automation for those requests is configured to route the request to review or if the request is routed to review by ARM because it cannot be filled by the lenders, then the associated ILLiad request will be routed to the Awaiting LVIS ARM Manual Review queue. You can then send that request through other workflows in ILLiad for fulfillment, such as to Rapid, either by manually routing the request or by configuring a routing rule that will automatically route requests from the Awaiting LVIS ARM Manual Review queue into another ILLiad queue for processing. If Rapid is unable to supply the article, you can then optionally send the request back through ARM using the default Awaiting ARM Sending queue to check your other custom holdings groups and apply other ARM automations you have configured.


If this article didn’t resolve your issue, please contact Atlas Support for assistance:

Contact Support