Library mailing addresses

Hi everyone,

We’ve been talking some about library bill-to/ship-to mailing addresses as we begin refining the orders app. As we started talking about it, we realized that other apps may be using library addresses as well. Note that these are addresses for the LIBRARY, not any vendor or external partner the library may be working with. In addition to orders, library addresses probably need to be included on patron notices, and maybe on fines/fees documents.

Our very provisional initial thinking is that libraries should have a way to create and store multiple addresses in some central way within their FOLIO tenant. Then any app that needs to work with a library address can access those central addresses. Maybe there are categories for those addresses (billing, shipping, patron-facing, etc.) to allow for filtering down the choices in various apps. Maybe they can be associated with individual teams (e.g. acquisitions units) within a tenant.

Are there other areas of FOLIO or library contexts where library mailing addresses come into play? Any other ideas or comments that we should be taking into account when figuring this out?

Going forward, thinking on the various Consortial multi-tenant setups, linked data scenarious etc that one can envision with FOLIO, I think this is a very good idea to keep this data in one central place.

I can think of some, stemming from having multiple library buildings on campus and staff spread all over them:

• We offer a library-to-library delivery service, so that a book stored at an inconveniently distant library can be checked out at the circ desk of another, more conveniently located building.

• Catalogers are mostly centralized in one office - but only mostly. If you need to send a physical book over to a specialized cataloger, it would sure help to have their address in FOLIO. Ditto receivers, etc. - anyone who has to handle a physical book.

• Invoices and other important documents often get sent to the wrong office, via both e- and snail-mail. Being able to look up who the document actually belongs to - whether the information you have is a name, or a bill-to address on the invoice that doesn’t match where it was actually sent, or what have you - would be a blessing.

• We have a number of units in possession of shared email inboxes, which may be not commonly known, or easily mixed up with each other. We’re also spread out over large enough spaces that any given staff member may not know where they can locate somebody in person to ask some urgent/complicated question. Associating units with both their group email addresses and physical addresses would greatly facilitate communication in larger organizations. Probably would be good to have some kind of note that describes what kind of work that unit does, too - sometimes you look at a thing and wonder, We do this thing?? Who even handles it?

• We also have a number of off-campus sites - not quite official library buildings, but places that used to have large official library presences and are now reduced to, like, one staff member in one room, handling the book delivery or reference or whatever.

I agree. Library addresses are relevant in e.g. Patron notices (Settings > Circulation > Patron notices

501812×1428 238 KB

It is a good idea to have a mailing address configuration module because:

1. We can configure if a mailing can be automated / manual / or both.
2. We can configure a specific printer by library and circulation desk.
3. Set mailing dates and times.
4. Fantastic, if we can link it with the workflow of library processes, from acquisitions, cataloging, circulation, etc. example: configure the long lists of books that go from acquisitions to the cataloging and cataloging area to circulation, if you could send an email with listings, great. Also manage the material in transit, ILL, resource sharing.

Another aspect of this to consider is the case of buildings with separate addresses for the public side and loading dock. Shipping addresses for incoming orders might well route to a different address than one used for patron correspondence. It sounds like this centralized approach, if done well, could reduce routing errors, etc. the main thing would be to have the appropriate structure such that different apps/workflows could have different default addresses, even within the same building.

Yes, definitely a good point, @dbottorff. Likewise, the business office where invoices are sent may be separate from the loading dock or patron correspondence address. I also have experienced addresses where all packages go to a central mail distribution address, and then there is an internal campus delivery system. So having the ability to create multiple physical and PO box addresses, and assign them to be used in various circumstances, seems helpful to me.

but where is the place to enter the library contact data?
Somewhere in the FOLIO “world” I read about the idea to have this per location, but in my opinion it is more reasonable to have it per library (in the institution-campus-library-location hierarchy).
There also should be a field for the name of a contact person.

Sorry to be so late, but maybe this needs to be considered in the context of locations. Can we leverage all of the existing locations (at least the hierarchical ones) to make this work? Just add a mailing address field (which they should probably have anyway).

Hi Andrea,

We’re hoping to specifically stay away from the library’s collection locations, since the mailing addresses may have more or less relationship to all those resource locations. Plus some addresses maybe central business offices or
campus loading docks that have nothing to do with the locations where the resources eventually end up being shelved. We thought about it, but decided it was best to keep the RM concept of locations separate from the concept of library mailing addresses. Do
you foresee any big issues if we keep them separated?

Ann-Marie Breaux

abreaux@ebsco.com

+1-770-557-5420

If the place to store library adress data would be the location level (in the location hierarchy) then it must be possible to copy existing adress data to other locations in a practical manner. Our libraries with a few hundred locations will have different addresses on the library level.
I would like to suggest:
place fields for address data on institution level AND on campus level AND on library level. The address data should be inherited to the next lower level if there is no individuell address data.

Supplement: also on location level…

We would like to have these fields:

• Library (official) name
• contact person
• phone number
• postal address
• e-mail address
• a field for the opening hours

The logic could be:
each field is inherited separately, so if there is no phone number on location level --> look at campus level and take the phone number from there.
If there is no phone number on calus level --> look at institution level and take the phone number from there.
If there is no phone number on institution level --> nothing to print on slips or notifications.

I’m not sure I understand the use case for an address for every location a library may have. Do you need addresses for Reference vs New book shelf vs General stacks in the Main Library? On the other hand, you may need general addresses like PO Boxes or Loading Docks that do not relate to one particular library location.

In your scenario, @UschiKlute , would there be multiple library contact people for different library responsibilities, e.g. patron-facing vs. orders vs. financials? How would the library contacts be used? When sending out patron notices?

For acquisitions purposes, we need some general addresses for shipments and invoices. They may vary from location to location, but more likely from one acquisitions unit to another and depending on how centralized or dispersed a library’s acquisitions work is. Maybe we should consider separate acquisitions addresses from patron-facing info like library name/address/opening hours. If that’s the case, maybe we just make some settings under Orders and/or Invoices, and let RA/UM go their own way. What do you think?

@Ann-Marie, you’re right: I only described the library address scenario for circulation purposes. In the ILL area we usually have the same postal address as for standard loans, but different contact persons, phone numbers and e-mail adresses. Perhaps this will be configured on location level, so there should also be the possibility to store specific adress data there. We have some large universities with 20-30 institution/faculty libraries additionally to the central university library. These institution libraries have their own names and individual address data also. Each faculty library would have a few locations.
The adress data should be used on patron notices, also on hold slips etc.

For acquisition purposes I think the best solution would be the ACQ Unit to store the adress data of that team. The adress data should be used as the sender e-mail adress for purchase orders, the PO itself would include the postal adress (and more) of the team as the vendor need this shipping address…

Yes, the adress data used in circulation will mostly be different from the adress data used in acquisitions.

Thanks for the clarification @UschiKlute

For other folks in this discussion thread - any objections if acquisitions and circulation go our own ways in terms of address-handling? There may be a bit of overlap, but we’ll likely use something in settings for acquisitions.

Meanwhile there is the possibility to have an address for the tenant. However, this is not sufficient, see my previous remarks.