Holds Routing Overview

The Holds Routing Sequences Primary and Holds Routing Sequences Secondary policy tables specify the RTF Requests-To-Fill or RTF processing sends hold requests to designated libraries in a specified order. A library chooses to fill or deny the request. The request is routed until it is filled, it expires, or every library denies it. routing sequences of hold requests from the requester branch to other branches, and determine whose items can be trapped An item is said to be trapped for a hold when an item that fills a request is scanned at circulation and the system links the item to a specific request, either automatically or by displaying a message that prompts you for a decision. at circulation to fill a request. Your Polaris Implementation Manager helps set up the tables when Polaris is installed, but you can modify them as needed. The Holds Routing Sequences Secondary table can be left empty if the branch does not use a secondary RTF sequence.

You can work with these tables from an organization workform or with the Administration Explorer. When you open the tables at the system level, you can view, add, change, delete, and reorder entries for any branch. At the library level, you can view, add, change, delete, and reorder entries for any branch associated with the library. At the branch level, you can view, add, change, delete, and reorder entries only for the specific branch.

Note:
These System Administration permissions are required to modify these tables: Access administration: Allow, Access tables: Allow, Modify holds routing sequence table: Allow.

For instructions on setting up the Hold Routing Sequence tables, see Edit holds routing tables. After setting up tables, you use the Request parameter, Holds options, RTF tab to set the total number of days in the RTF cycle and specify how the requests are filled. See Set Holds options: RTF processing.

Request to Fill (RTF) Routing

In Polaris, the specified pickup branch for a hold request (not the patron’s registered branch) is the “requester” branch for the purposes of RTF routing. Each branch can specify the RTF routing sequence that the system uses when that branch is the pickup branch. When you set up a routing sequence for a requester branch, you are effectively defining the branches with which the requester branch can do the business of hold requests, whether items are taken off the shelf as part of RTF processing or trapped at circulation.

A branch can specify a primary routing sequence alone, or both primary and secondary routing sequences. This allows a library to establish levels of priority in filling hold requests. In a system where libraries are geographically close and have fairly uniform lending policies, a branch may define only a primary group of RTF branches, allowing a request to pass from one branch to the other in a preferred order. Leaving a branch out of a routing cycle will prevent your items from filling requests at that branch. You might do this, for example, if a branch has closed temporarily.

If the concern is not just to fill requests from any branch as efficiently as possible but to first check with a specific group of branches (such as geographically close or politically allied branches) the library might place itself and a few other branches in the primary group, but place other libraries in the secondary group. Then a request is routed to the secondary group only if the primary group does not have the item.

Note:
You can set Polaris to randomize the request sequence so that the same library is not always the first asked to fill the request.

When you use primary and secondary routing groups, and a request is routed to the secondary group, the position of the request in the holds queue may change. If you think this might confuse patrons, you can suppress the display of the holds queue position in PAC and Polaris ExpressCheck. For PAC, set the PAC profile Patron access: Display hold queue information to No. The profile setting for the patron’s registered branch controls whether the holds queue column is displayed in the online patron account, and whether the patron receives a message about the current number of active requests for the material when she places a hold. For Polaris ExpressCheck, open the SelfCheck Unit parameter Polaris ExpressCheck enable and clear the Display hold queue position checkbox.

Note:
It is neither necessary nor desirable to include the same branches in both the primary and secondary cycles as this defeats the purpose of separately defined groups. Also, when a request passes to the secondary routing cycle, an item that checks in to a primary branch will still trap for the request.

The illustration shows an example of primary group routing.

rtfprocessing.gif 

For each branch (and in each routing group, if you use both groups), the following information is defined:

Important:
Each branch should put itself in the first position (sequence of 1) for the Primary table’s Responder column. That way, the request can be filled first by the requester branch, if that branch has an item that is In. If the branch is not listed as a responder branch for itself, its own items do not trap for holds at circulation. If you use secondary groups, you would probably not want your branch as a responder branch in the secondary group, since the branch would be polled again if the request went to the secondary group. If a request does go to the secondary RTF group, an item can still be trapped at any branch in either group.