Circ Desks/Service Points

Please note: This post highlights our current thinking on this feature. Please help us improve it — share your questions, constructive feedback and ideas in the comments below.

Let’s discuss circulation desks.

Circ desks are not locations. For more information on locations, see this discuss post.

A Use Case

• As a circ desk worker who has checked in an item
• I want to know whether the item is “home” (close to it’s selected location) or if it needs to go in transit to its home
• So that I know what needs to be done to get it reshelved

Proposal

• FOLIO will support CRUD (create, read, update, delete) of circ desk records
• Circ desks can be associated with locations so that, when an item is checked in at a circ desk, the system will look at the location associated with the item and know if it is “home” or needs to go in transit to its home location
• NOTE: Circulation desks may NOT have loan rules directly applied to them

Wireframe
This wireframe shows a proposed Create New Circulation Desk form: https://drive.google.com/file/d/1SrKgSPpWOX3qqu50gDFxWwvRVDVa7SQQ/view?usp=sharing

Questions

1. Does this seem like the right approach?
2. What other use cases relate to circ desks? Some possibilities:

• View circ desk at which a loan was initiated in the loan actions table on Loan Details
• Change location (circ desk?) at check-in
• Indicate pickup location (circ desk?) for requests
• Limit scope of user permission by location (or circ desk?) - It was suggested in an earlier meeting that permission scope (for FOLIO operators) may be limited by circ desk, rather than location. Is there really a need to have different permissions based on the circ desk you are working at? It seems like scoping permissions by location might be more valuable, especially in the case of single-tenant consortia setups. Thoughts?
• Customize calendar (open/closed days and hours) by location (circ desk?)
• Etc.

3. Does it make sense to leverage the circ desk object for other operational processing centers like binderies or ILL offices? If so, should we use a more generic term like “processing center”? EDIT: @andrealoigman suggested “Service point” which I really like. Thoughts?

Thanks in advance for your input!

#1: This looks good to me Cate. It seems like the right approach overall. it seems to recall that Voyager has additional settings here that might be useful (but I can’t for the life of remember what they are). Maybe someone from a Voyager library could upload a screen shot.

#2: Assuming 1 to 1 relationships

• Pick-up locations should indeed be circ desks not shelving type locations.
• We need to limit scope of user by desk. - - - staff / students may be limited to working at specific desk(s), but will have to check-out materials from locations not associated with that desk if they are delivered there for pick-up. From a circ perspective, most location based restrictions should be able to be controlled with circ rules.
  - n.b. - We still need to figure out how to keep people without permission from working remotely while still allowing those with permission to do so.
• Circ desks should be associated with calendars (as opposed to the other way around). This would allow us to create calendars and associate multiple desks with them rather than having to maintain a separate calendar for each desk. We’d need to be able to see the associated calendar from the desk configuration screen. It would be good to select it there as well, but if the connection can only happen in one place it would be better from the calendar side.

#3: This is certainly how most of us make this work now (non-pick-up locations), but this is also where many to many relationships would start to become useful (even though it messes everything else up). Will need further discussion. I think that if we had a workflow engine and could associate service points/circ desks with engine rules, that would allow points to do double duty without adding many to many relationships to the mix.

. . . and on the name thing. ‘Circ desk’ is less accurate, but shorter to say. ‘Processing center’ is just a mouthful. Maybe a compromise and try for ‘service point’?

This approach looks promising. I do think a broader name like ‘processing center’ would preserve important opportunities like ILL, Repair, Decision Shelf.

You say Circ Desk is not a location; is it wise to allow the “/” to be used in naming a Circ Desk since that is used to demarkate location codes?

Thanks,

Mark

The overall approach looks good.

Circ desks definitely need to be associated with locations for checkin. They also need to be associated with locations for which they are valid pickup locations. For example, perhaps the humanities library is not a valid pickup location for engineering library material. It would be very useful to have the number of days a requested item will be kept on the hold shelf associated with each pickup location (circ desk). UC has a standard length, but I’m sure there are institutions that do not.

The circ desk should be changeable from both the loan screen and the checkin screen (with proper permissions). There are cases in which one workstation serves two functionally different “circ desks”.

I see limiting the scope of permissions by circ desk not as having different permissions at different circ desks, but as being authorized to use one or more circ desks. It could be useful, especially in the broader sense of “processing centers/service points”, to have different permissions by service point. A staff member might be authorized to do cataloging at one service point, but only checkin at another.

The calendar needs to be customized by circ desk. It is definitely best to have calendars which can be associated with circ desks. There will be multiple circ desks per calendar, but exceptions within the same location (library?).

I think there do need to be circ desk like objects for processing centers/service points that are not circulation points. I’m not sure if they need to be the same object. Some functions do overlap. ILL, in particular, can have circulation functions.

The approach looks good to me! Here some thoughts:

• Yes, associating desks with (existing global) calendars will likely be more efficient than doing it the other way round.

• Some desks/service points may have printers that need to be associated with them. They might be used for local client based printing and server side network printing.

• Shall gates (gate tracker) be associated with desks/service points?

• Is a transit desk also a circulation desk/service point? Items retrieved from our closed stacks in some cases move through more than one desk until they end up with the patron.

• Hooking up loan rules with locations rather than desks or logins would be a great relief for us.

• A logical desk/service point could have self service stations/shelves and/or staff using a client.

• A (future) hold shelf could have RFID sensors and tell patrons exactly when a book has been shelved for pickup.

Thanks for the great input, @andrealoigman! Could you upload screenshots of how permission assignments are limited by circ desk in Aleph? I’ve created a folder in our Google Drive.

#3: This is certainly how most of us make this work now (non-pick-up locations), but this is also where many to many relationships would start to become useful (even though it messes everything else up).

Do you have any specific thoughts on how a many to many relationship between circ desk and location might mess things up? It doesn’t seem to cause any problems for the is-this-thing-home-or-not use case…

Finally, I really like “Service point”! I’ll edit the main post to see what others think of it.

Interesting point, @mac609_lehigh. Honestly, I’m not sure what the code is used for, I just saw it was collected in OLE so I added it to my wireframe. Do you know how these are used?

Thanks, @cmalmbor! In OLE (see screenshot), a circ desk has a flag for pickup location true/false. There is also a “default location” field. Is this the field that supports the functionality you need? Could you tell me how that is used?

Another way of meeting this requirement might be to have a pickup location yes/no flag associated with the location to circ desk assignments. That’s definitely complicating, though.

What functional impact does the circ desk have at the time of check out?

If I’m understanding correctly, these comments seems to conflict. On the one hand it seems you are suggesting would could just authorize users to use one or more circ desks and their permissions would be the same regardless of which they are using. On the other hand, it seems you do think it would be useful to have permissions differ by service point (e.g. circ desk). I’m curious, what does OLE do? Can you please post a screenshot to this folder? Does OLE’s current approach work for Chicago?

Thanks!

Thanks Carsten! I did see that in OLE (see screenshot), the circ desk/service point form had a flag for “print slip” true/false. We can certainly do something similar in FOLIO if that makes sense for printing functionality. Tagging @dbranchini for awareness, as she’s the PO for printing slips.

Say more about “gates”. What are they? What do they do?

I’m not sure. How does your system handle this today? Do you have thoughts on pros/cons of this approach?

Thanks, Cheryl. We have already specified that you can manually set a hold shelf expiration date for a request when the requested item is checked in. Would the hold shelf expiration set in the circ desk/service point record serve as the default? If that’s the case, my next question is how often do you manually change the hold shelf expiration at the time of check-in? Tagging @taniafersenheim for awareness as she’s the Requests PO.

We use RFID-tags to identify, process and secure our items. The entrance/exit of our self service stacks is equipped with RFID-gates. The gates are hooked up to a PC with gate tracker software and an interface to our ILS. Upon an alarm (book taken out but not (self-)checked out) the PC shows the titles in question.

In my experience hold shelf life (aka hold shelf expiration) frequently varies by service point and occasionally varies by format - e.g. media, bound journals or ILL materials may have a different hold shelf life than standard books. This isn’t something that seems to change often once it’s set up. It’s way too confusing for patrons.

Our current ILS does not handle this. We have a complicated workflow with ILS (LBS), discovery (VUfind), mail software and “paper” for ordering items form a closed stack (central libraray) and having them delivered to priviliged person’s (some professors in certain departments) offices through department libraries. The central libraray puts an item on an ILS “department libraray account” at the “transit” desk. The department library later processes the item and puts it on an extra “paper” based patron account. The patrons have an ILS account too and don’t see these items there… There must be a better way…
Our “transit” desk allows for local pickup too - preferred by us, but not professors on remote locations.

Cate,
It is not practical to have staff manual set the hold shelf expiration date as each requested item is checked in. It is too time consuming and prone to error.

There needs to be a default preferably at the circ desk level, but definitely at a more granular level than the institution.

I think we very seldom change the hold shelf expiration date. It is probably done only if a patron requests it for a valid reason or if there has been a problem with hold notices.

OLE maps staff operators to circ desks. There is one default circ desk that comes up when the staff member logs in. The person can also be authorized to change to one or more different desks. See the screen shot circ_dsk_staff_map. Functional permission as set separately for each staff member. They apply to all circ desks.

This works for us now. I was just speculating on how things might change if the concept of circ desks was expanded to service points.

If these become service points, does this replace the Fee/Fine Owners table? It seems like we could add a flag to the service point indicating if fees/fines are owned by the service point rather than having a separate Fee/Fine Owners table.

On pickup locations:
The pickup location flag for a circ desk indicates that the desk is a potential pickup location. Some circ desks are not pickup locations; they do not have hold shelves.

In OLE the default pickup location is just the pickup location used if none is specified in the request. So only one circ desk is specified as the default for all requests. It also forces the default location to the top of the list of possible pickup locations on the request screen.

Besides specifying that a circ desk is a pickup location, we need to specify for which locations it is a valid pickup location. Location in this case refers to the home location of the item being held.
OLE handles this very awkwardly. Each location, down to what would be a parking level, that a circ desk can hold items from needs to be listed as a “pickup location”. Hence 9 screenshots for the circ desk setup. The terminology is confusing. The locations under the header “Pickup Locations” means that this circ desk can accept hold items from the item locations listed.

It would be easier for setup to be able to list locations at a library level and make exceptions at the parking level.

On changing the circ desk at checkout:

I need to defer to David Bottorff on the importance of this. It is probably not too common for us in reality. One use case I can think of is if an item from a location that a circ desk is not valid to service is presented for checkout the circ desk could be changed to a valid one in order to check out the item. The point is to not to unnecessarily hassle the patron who is legitimately trying to check out an item that had been misplaced.

In OLE, a staff member can be authorized for several circ desks, one of which is the default on login. Staff need to change from that default if working at another desk. If the circ desk is not changed any items will be recorded as checked out at the wrong desk.

I wonder if a default desk should be hooked up to a login or a PC. Our staff serves at different desks, of which only one would match their personal default desk. Adding a default parameter to the desk icon for each PC might be helpful.

I will defer to others as to how often a staff member may need to change service points at checkin/checkout, but I wonder, if it is a rarely performed action, would it be effective instead to have an override permission that allows a staff person to check out/ in an item that is not “allowed” at that service point?

The data would then be accurate as to where that action actually physically took place. If the checkout or checkin location were changed, when something is physically handled at location A - will the transaction appear to have happened at Library B and, if so, would that ever become an issue with tracking down an item that’s gone awol?

My experience has been that the Hold Shelf expiry period is tied to a service point (hold shelf) and that exceptions are made manually, but rarely.

It is an interesting idea to be able to set an expiry period for certain kinds of material that differs from a default set for the service point.

In our current implementation we have virtual service desks for ILL and staff who toggle between service desks. They need to change service desk for a short session and, so, an override for each transaction would be unworkable.

Perhaps FOLIO will be able to differentiate ILLs from other loans - for example by evaluating item, borrower or a request information. If a (desk) user can then have multiple roles, toggling between desks might not be necessary anymore.

Sorry Holly - just spotted this. The owning library is generally based on the shelving location rather than on the circ desk/service point. While I can see advantages to changing it, the many to many relationship between shelving locations and service points will likely make it impossible.