Elizabeth Wright · Cook Room · Gatherings Track · Tuesday, April 14
Speaker: Elizabeth Wright
A roundtable discussion among Sierra libraries of varying sizes — from 12-branch systems to a 129-library consortium — sharing practical experience with floating collections, the tools they've built or adopted, and the gaps that remain. An Innovative staff member joined to gather input on Vega Reports priorities.
| System Size | Float Status | Key Tools |
|---|---|---|
| 79 locations / 39 branches | Active float, fully mapped | Library IQ |
| 24 branches (Tulsa City County) | Active float | Library IQ, vendor grids |
| 12 locations (growing to 14) | Pilot projects | Custom Sierra API tools |
| 129-library consortium | Exploring — potential new member | Sierra float rules |
| Cincinnati & Hamilton County PL | API development | Custom bulk-hold web app |
Multiple libraries use Library IQ to map entire collections and set optimal shelf sizes per area. Librarians see which branches are "pooling" (over capacity) and which are in "drought" (under capacity). CollectionHQ (Baker & Taylor) is also in use for evidence-based stock management.
In 2024, Innovative partnered with Library IQ to offer analytics within the Vega LX portfolio. Decision Center (Innovative's legacy analytics product) was discussed but is being de-emphasized.
Knowing you need to move 10 items from branch A to B is helpful, but no tool provides good criteria for which specific items to move. Participants wanted filters based on: last checkout date, item created date, total circulations (including zero-circ items), and whether the receiving branch has seen the title recently.
All branches mapped with defined shelf capacity. Staff instructions for pulls: "Send 100 picture books. Pull A through Z. Don't pull everything from one area. Avoid duplicates." Typical float volume: 50–300 items between branches. Title-level pick lists were abandoned — nobody has time to process item-by-item lists at that scale.
Initial resistance is strong, but libraries don't want to go back. Branch staff have deep ownership of "their" shelves. If you say "pull 20 items," staff will pull the worst — they want to keep the best for their customers. One system avoided floating juvenile nonfiction because they feared staff would game the system.
But after about a year of floating, one system offered to let branches opt out. They unanimously refused. The constant refreshment of paperbacks, media, and large print was too valuable.
Float timing is constrained by delivery schedules. One system sends requests Monday (busiest delivery day) so staff can start sending Wednesday when trucks are lighter. The day with the lowest delivery volume is the best day to trigger automated float requests.
When branches need items for programs, displays, or to fill collection gaps, the standard answer is "just place holds." But this is tedious — staff have to search individually, find available copies at other branches, and place holds one at a time. Several libraries have built API-driven tools to automate this.
A web application using the Sierra REST API allows staff to import a list of barcodes (a "shopping list") and place bulk item-level holds to route everything to a target branch.
Key innovation: Sierra enforces a ~2,000 hold limit per patron card. Rather than juggling multiple admin cards, this tool creates a temporary patron account on the fly via the API — patron expiration and "not needed after" date both set to 30 days. Each batch is a self-contained, trackable unit. After 30 days, the patron and unfilled holds auto-expire.
A consortium participant shared two complementary tools:
For their floating pilot, they automated return-to-home with a weekly script: any item on the shelf longer than X days gets a hold placed to send it home. Set to run on the lowest-delivery day to avoid overwhelming staff.
Several participants raised concerns about hold contention — bulk holds can impact patron access and add paging burden. The group discussed using item status codes instead: a dynamic "shopping" status with auto-expiration (similar to how "missing" has stages). Sierra's Circa tool already supports batch status changes via barcode scanning.
The blocker: Sierra Scheduler can't currently execute API calls. If it could, libraries could chain Create Lists queries with API-driven status changes on a schedule.
When you place a hold via the Sierra REST API's POST endpoint, the response is HTTP 204 No Content — the body is empty and no hold ID is returned. Since holds aren't a first-class record type in Sierra, there's no reliable way to programmatically track a specific hold after placement.
Workaround: immediately GET the patron's hold list and identify the new hold by timestamp or record number. This is fragile and doesn't scale well for bulk operations.
Sierra API docs: Documentation (v6.6) · Interactive sandbox · Developer portal
Sierra stores only current state for item locations. There is no built-in way to answer: Where has this item been over the last year? How long does it take to get from branch A to B? What is the actual flow pattern of our floating collection?
"Administration always asks how long it takes to get from A to B. And you can't answer that."
Items passing through a sorter while already checked in produce no circulation transaction — no status change means nothing is recorded. There's no shipping/tracking log for physical items.
| Approach | How It Works | Limitations |
|---|---|---|
| Collection snapshots | Dump entire collection locations at regular intervals, diff over time | Storage-heavy, requires custom tooling |
| Annual checkout rankings | Rank branches by format checkout frequency to inform float decisions | Only annual granularity, reactive |
| Inventory check-in analysis | Check in every item over a month; analyze where things ended up | Recent improvement — now creates transactions |
Vega Reports (launched April 7, 2026) is expected to create a data lake with regular snapshots of ILS data. If it captures item location changes over time, it could solve the historical tracking problem. Currently surfaces Vega Discover data; Sierra ILS integration is on the roadmap.
The concept: Instead of float rules that simply say "this item type floats between these locations," the system makes intelligent routing decisions at check-in based on real-time collection state.
Example: A copy is returned at Branch A, which already has 8 copies. Branch B has only 2 and hasn't seen this title in 18 months. The system creates a transit request to send it to Branch B.
Automated sorters already implement routing logic at check-in. Polaris has related functionality. Lyngsoe Systems' IMMS is an RFID-based platform that tracks every item movement and supports automated routing — a hardware-based version of what this group wants in software.
Sierra's own floating collection configuration supports rule-based float at check-in, but lacks the dupe-aware, capacity-aware intelligence discussed here.
Elizabeth Wright committed to submitting this as an Idea Exchange enhancement request. The group's advice: don't just click the vote button — write a comment with your library's specific use case. Reach out to other floating libraries to build support. Even contact non-floating libraries: "You might want to float someday."
How do you ensure new acquisitions are distributed fairly when items naturally drift toward high-demand branches? Small branches with heavy reader populations see popular items float away quickly.
| Strategy | How It Works |
|---|---|
| Rotating vendor grids | Acquisitions grids cycle through branches — small branches get the same percentage of new items as large ones |
| Assign to one branch | For high-hold items (Lucky Day / Quick Picks), assign to one branch — holds will distribute them naturally |
| Percentage-based allocation | Allocate new items proportionally so no branch feels underserved |
A library with an existing floating collection wants to join a 129-library consortium where no one else floats.
Sierra's float rules are scoped to the floating library's own locations. When a floating library's item is returned at a non-floating consortium member, it goes in transit back to its owning location — the same behavior that already happens for all non-floating consortium items. The floating library sets up float rules for their own branches; the rest of the consortium is unaffected.
An Innovative staff member gathered input on reporting priorities. See also: Vega Reports announcement
| Component | Detail |
|---|---|
| Platform | Metabase — open-source BI tool (GitHub) |
| Query builder | Visual drag-and-drop; generates SQL behind the scenes |
| SQL access | Direct SQL editor for power users (role-dependent) |
| Current data | Vega Discover metrics (visitors, engagement, search activity) |
| Roadmap | Polaris ILS, OverDrive checkout data, Sierra ILS |
Datasette (GitHub) by Simon Willison was mentioned as a comparable open-source tool already in use at one library. Publishes any SQLite database as an explorable website with faceted browsing, full-text search, and a JSON API. Companion tool sqlite-utils converts CSV/JSON into SQLite from the command line — a lightweight alternative to a full BI stack.
Libraries that float are committed to it, but Sierra's tooling — especially around intelligent routing, item tracking, and bulk operations — lags behind operational needs.
Multiple participants have built custom applications using the Sierra REST API: bulk hold placement, automated return-to-home scripts, collection movement tracking. A testament to the API's value and an indicator of unmet product needs.
Every library at the table wanted to know where items have been, not just where they are now. Vega Reports' data lake could address this if it captures location snapshots over time.
Capacity-aware, dupe-aware routing that doesn't require hardware sorters was the consensus top priority for the Idea Exchange.
Libraries with data analysts can get what they need via SQL. The first release of any new reporting tool should prioritize ready-to-use reports for smaller libraries without dedicated technical staff.
