I have spent hours mapping out circulation rules the last few weeks in preparation for a pilot project we are about to run at my library. In the process, I have learnt a great deal about circulation parameters and privileges that I’ve put together in a brief primer below. If I missed anything, please let me know.
First off, a big thank you to all the support folks at SirsiDynix for walking me through some of the weird situations I’ve encountered over the last year, which has helped me build the knowledge necessary to write this.
Global Circulation Setting
The matham (system wide parameters) has a couple of settings that have a major effect on circulation. They’re all fairly obvious and explained in the manual, but just a reminder that:
Circ Settings by:
- Item’s Location, or
- Circ Location
can make a big difference to how the rules are applied. The main thing to keep in mind is that all “location” settings in the parameters are based on this setting.
Parameters vs. Privileges
Anyone who administers Horizon will know that circulation rules are found in two main areas:
- circ parameters, and
- circ privileges.
What’s the difference?
| Parameters | Privileges |
|---|---|
| More Global | More Specific |
| Can Specify Location | May Be Per Location |
| Does not allow Staff Override for Y/N rules | Always Allows Staff Override |
| Does Not Overrules Privileges | Will Overrule Parameters |
Most parameters and privileges control different things, so one overruling the other is not really a concern, but there may be cases where they overlap or do almost the same thing and presumably, the privilege overrules the parameter because it’s more specific.
Requirements
To properly understand circulation rules, you need to have a good understanding of borrower types (btype), item types (itype), and their respective groups. If you’re unclear of how these work, the circulation administration manual is fairly good at explaining them.
While not a requirement, I also recommend either SQL access or a good understand of how to use the “Where clause…” option within the client.
Administrator Views
Under the Table Editor, you will find a number of views related to circ (if you’re missing any of these, you may want to enable them):
- circ_parameter
- circ_privilege, which allows you to search
- circ_privilege_code, which lists all privileges for all locations
- btype and btype_group
- itype and itype_group
- itype_group_itype, which allows you to search itype groups
Unfortunately, parameter does not have a built-in view with a search, so you can either use the where clause function to narrow down the list, or use this SQL query:
[code]
select circ_parameter, btype_group, itype_group, value
from circ_parameter_matrix
where itype_group = ‘xx’
[/code]
Types and Groups
As it’s a bit out of scope, I won’t go into detail, but the main thing to keep in mind is that the rules will apply to the whole group. In most cases where you are (not) allowing something, that’s fine, but in some cases, where you set specific limits, remember that it applies to the whole group. For example, if you set a max number of “all CDs” checked out, then the borrower is limited to X number of all the itypes you include in the AllCDs, such as music CDs, Audiobooks, and educational CDs.
The Rundown
A quick note that there are a lot of parameters and privileges that we don’t use or should be fairly evident, so I will actually cover very few of the parameters and privileges with the focus on those where something seemed very non-intuitive (at least for me).
Holds/Requests
Requests can be controlled in two ways:
- total number of holds by btype (parameter 4), and
- preventing requests for specific itypes (as exceptions in parameter 29).
The number of holds cannot be limited by itype. The way Horizon works is that when holds are at the bib level (which they typically are), then it will check whether the request is allowed based on itype, but otherwise does not look at the itype. In order for parameter 34 (max requests for itype) to work, all holds must be made at the item level, which I have never heard of any library doing.
This is further explained in the SirsiDynix support article on borrowers exceeding the limit of requests on certain itypes (login required).
Hourly Same Day Loans
This is a bit of an aside since it’s not directly involving either parameters or privileges, but one of the relatively new things we wanted to do was have hourly loans that had to be returned by the end of the day.
Ensure that you have privilege 1 (Loan Periods) and privilege 2 (Renewal Period) set with the correct itype and hourly loan and renewal periods. Once set, you will need to make sure the itype has the following two settings:
- Bookable: Checked, and
- Take Overnight?: Unchecked.
Max Items Check Out
Here is where things get a little confusing, because there is both a privilege (11) and parameter (53) where the wording is similar and sort of do the same thing, but don’t.
The main thing to consider is how you want the maximum number of items to apply.
Privilege 11 is location independent, so will apply the maximums (as specified in the exceptions) for each location separately for each borrower. For example, if a borrower is limited to 2 video games, they could borrow 2 from location A and 2 from location B.
Parameter 53 is system wide, so will apply the limits across locations for a borrower, so using the same example, if they check out 2 video games at location A, they cannot check out anymore video games regardless of which location they go to.
Which of the two you use really depends on the system, but most systems I would imagine will want to use the parameter.
When setting up either one, be aware that the “default” value is the total number of checkouts allowed per borrower (not as I thought, the default number per itype allowed). The exceptions limit the number of items by itype or itype group specified.
If specifying an itype group, remember that the number you specify is for the whole group. For example, you have different DVD itypes (because they have different fines or loan periods), but you want to limit the total number of DVDs a borrower is allowed to check out. The best way is to create an itype group with all the DVD itypes and apply a single exception with the limit for the itype group.
Note that there is also parameter 44 (Global maximum of checkouts). This parameter literally specifies “a maximum number checkouts allowed globally for all locations on the system” (see issue HZO-3506 (login required)), which I’m sure has a use case since it was added in the system, but I honestly can’t think of one at the moment.
Renewals
What can be confusing about renewal privileges is that they are all separate, and do not overlap. There is no single “global” setting for all methods of renewals, so you need to make sure that all your renewal settings are repeatedly, and consistently applied across all these privileges:
- 3 Maximum Number of Renewals (via staff client or self-check)
- 4 Maximum Number of Phone Renewals
- 24 Allow OPAC Renewals
- 25 Maximum OPAC Renewals Allowed
- 26 Allow OPAC Renewals on Overdue Items
Since the rules need to be duplicated so many times, renewals is an area where itype groups will be particularly helpful.
Take Away
Hopefully this brief primer is helpful. Horizon can be a bit confusing when it comes to circulation rules, so my take away though is to make sure to test the settings and if it’s not behaving as expected, then double check the knowledge base and if need be, contact support.
If you notice any errors or have any additional notes or stories to share, please comment below or contact me!