Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-1516

Automated Storage and Retrieval System Requests



    • New Feature
    • Status: Draft (View Workflow)
    • P5
    • Resolution: Unresolved
    • None
    • None
    • None
    • Vega
    • 5
    • 22
    • Hide
      2020-10-04 - CB: Making my PO rank same as the calculated total rank for now.
      2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
      2020-10-04 - CB: Making my PO rank same as the calculated total rank for now. 2019-07-12: Keeping PO rank same as calculated rank (with potential minor adjustments to avoid having two features with same rank)
    • R5
    • R1
    • R5
    • R5
    • R4
    • R5
    • R5
    • R1
    • R5
    • R1
    • R4
    • R5
    • R5
    • R5


      Automated storage and retrieval systems like the one at University of Chicago come with a unique set of needs. When a request comes in for an item stored in the ASR, it must be flagged in such a way that the ASR system can detect the presence of a new request so it can be retrieved by robotic arm. For this purpose, we have designed a new request type called "ASR Request".

      Current thinking on design:
      Note: this feature was defined in collaboration with dbottorff and cmalmbor of University of Chicago

      • New request type "ASR Request" is created in FOLIO
      • New item (availability) status "Available in ASR" is created in FOLIO
        • This item status can only be set in FOLIO by an integrated ASR system (if there is one)
        • This item status is pushed to FOLIO when an item is stored in ASR (it overrides whatever FOLIO status would have otherwise be set)
        • This status would only be applicable to institutions using ASRs and, therefore, wouldn't interfere with workflows for institutions not using this type of storage system
      • When a request is made for an item with item status "Available in ASR", the only possible request type is ASR (this is very analogous to how Page requests work for Available items)
      • ASR system polls FOLIO for new ASR requests
      • When a new request is identified, the ASR system begins to retrieve the item and pushes a new item availability status to FOLIO called "Retrieving from ASR"
      • The ASR delivers the book to a library staffed service point
      • The entire process from request creation to item delivery takes less than 3 minutes
      • Library staff scans the item in FOLIO check in app
      • Item goes into "Awaiting pickup" or "In transit" depending on the pickup service point specified in the ASR request (this part of the process is already working)
      • When an ASR item is returned, it goes into Recently returned status like all other returned items (assuming your institution uses the Recently returned status)
      • When the item re-stored in the ASR, the ASR again pushed the "Available in ASR" status into FOLIO
      • This new type of request has been added to the request whitelist document (you may have to unhide columns and rows to see it)


      • Why can't we just use Page requests for this?
        1. If we used Page requests, we'd need some other mechanism for automatically identifying pages for ASR vs pages for non-ASR.
          1. This could be done by item location, but there are a few issues with the location-based approach:
            1. We'd need to develop the ability to flag certain locations as ASR locations
            2. The system(s) would then need to traverse many tables to determine whether the request is an ASR request or not. Assumption is that this would be slower with more points of failure.
            3. Also, there are some cases where something is stored in ASR and the item location isn't properly updated (this is an error, but it happens)
          2. Alternatively, ASR requests could be identified as page requests where item status = Available in ASR
            1. This might be less problematic than the location-based approach
        2. Still, if we used Page requests, we'd need to make sure to exclude ASR requests from staff picklist reports for regular pages. Of course, picklist reports will need to be filtered by location, but there could be locations that contain ASR items and regular collections.
        3. Leveraging Page requests would also make it more difficult to get statistics on numbers of ASR requests vs Pages
        4. Overall, it feels like the distinct request type is simpler, requires less conditional logic and wouldn't be very difficult to implement
      • Why would we make this a general feature?
        1. While it's relatively uncommon, there are institutions that use ASRs and our assumption is that this feature could work for many of them (there are only a few vendors for these kinds of systems so, chances are other institutions are using the exact system Chicago is using)

      Final note: These types of systems are very expensive and very high-visibility in their institutions. It is extremely important that they work well and they work fast.

      TestRail: Results


          Issue Links



                Unassigned Unassigned
                cboerema Cate Boerema
                0 Vote for this issue
                5 Start watching this issue



                  TestRail: Runs

                    TestRail: Cases