Cornell universaty related business logic is in blue.

Duke universaty related business logic is in red-purple.

Accession flow

Accession flow initiated by Remote storage system. 

1. Remote storage system calls into Folio Edge API to retrieve bibliographic metadata related to item (identified by barcode). Folio returns the following bibliographic information : title, primary contributor, ISBN, call number, enumeration [volume and year], ISSN, identifier, holdings record (only for the item that was accessioned).
2. Folio changes the item’s permanent location to the final location (remote), which is looked up in accession table.
3. In order to look up the final location (remote) for item Folio should find an appropriate location in accession table (aka Location mapping table) by current effective location of the item and remote storage configuration id (for the Caisoft instance). If there is no appropriate mapping in the accession table, the exception should be logged to the logs and accession should be stopped.
4. FOLIO checks the permanent location of the current item’s holdings record (hereinafter original location of the holding).
   1. Cornell (for the remote configuration the "Holdings handling workflow" is set to "Change permanent location"):
      1. If the holdings record has not the same location, as item final location (remote) the location of the holding should be changed to item’s final location (remote). (If one item has a remote location, the holding must have the same remote location)
      2. If the permanent location of holding is changed and there are items in the holding for which neither permanent nor temporary location are specified, Folio (remote-storage module) should set the permanent location for such items to the original location of the holding.
   2. Duke (for the remote configuration the "Holdings handling workflow" is set to "Duplicate holdings"):
      1. If a holding's permanent location matches the final location (remote), no actions should be done.
      2. If a holding's permanent location doesn’t match the new item’s permanent location, FOLIO checks the items in the current holding and compares them with items from the remote storage request.
      3. If all other items from the current holding have the same permanent location, as the accessioned item (final location (remote)), or will have the same permanent location according to the barcodes in the request (if it is a bulk accession request - consider whether we have it), then the current holding's permanent location is changed to the final location (remote). 
      4. If not all items from the current holding have or will have the same remote permanent location (the final location (remote)), FOLIO checks the current instance for the existence of a holdings record with a location which matches the final location (remote).
      5. If such a holdings record is in place, the accessioned item is automatically moved to this holding
      6. If there isn’t such a holdings record
         1. Сurrent holdings record is automatically duplicated
         2. Holdings permanent location is changed to new final location (remote)
         3. Item is moved to created holdings record

NB: Electronic resources are out of scope for Cornell.

Accession table

There should be 3 coulmns in accession table: remote configuration id, original location, final location (remote). Previosly for Dematic there was a one to many mapping between Remote Storage Configuration and Remote Locations. This table should be adjusted to have additional column original location. And for Caisoft to find appropriate final location (remote) there should be a query by remote configuration id and original location. On UI this table should be presented in Folio Configuration. The left column should be original location and it should have the values for all non-remote  location in Folio for tenant. For each location user must select appropriate remote location. Also in this table there should be column customer code (this requirement could be deprioritized).

Requesting (Retrival) flow

1. The process starts from a Page request, created either by library staff via FOLIO or by patron via Discovery service (Hold or Recall requests are described in the Return process)
2. FOLIO understands whether the request to remote storage should be done by checking item’s effective location:
   
   1. If item’s effective location is remote - Circulation Request is sent to retrieval requests queue
3. There is a background retrieval request job which operates by schedule (schedule can be configured individually for each remote storage). Each run the job takes all items in the queue and sends them to the Remote Storage retrieval request endpoint.
   1. Caiasoft require the minimum info for a request in Caiasoft is the following: type (Physical Retrieval, Scan Request), item identifier (barcode), reuqest service point (circulation stop - library and/or desk to which the item is to be delivered).
      1. NB: In Caiasoft, there is an area to map info to stops - so it can be handled on the Caiasoft side "when FOLIO sends X in the stop field, assign to Caiasoft circulation stop Y" and can be set up one to one, many to one, etc.
4.   
5. Remote Storage response indicates whether an item is successfully requested or rejected (with rejection details).
   1. If item was successfully requested, item is deleted from the retrieval request queue. 
   2. If an item is failed to be requested because of a server error, FOLIO keeps the item in the queue.
   3. If an item is rejected because of a logic reason (item not found, item is locked, item is out of the container etc) then the item is deleted from the queue and error is reported.
6. After receiving a request Caisoft Remote Storage System sends a notification to FOLIO item status update, which should trigger automatic check-in of the item in FOLIO to the primary service point for the item's effective remote location.
   1. Printing slips are out of scope

Returning flow

1. This process is triggered when an item with remote storage as its effective location is returned after being checked out, or a request was cancelled.

If an item is being checked in and the item’s effective location is remote and there are no open requests on the item

1. FOLIO checks if there are any requests for returned item (standard circulation process)
2. For an item stored remotely and returning back to its home location, its status becomes “In transit”, since it should not become “Available” until it is checked in in FOLIO. It is implemented, no logic is needed.
3. The next steps are different de[ending on setting: "Returning items workflow"
   
   1. Cornell ("Check-in in Folio"):
      1. When a remote item is checked-in to the service point (in FOLIO from a user at the remote storage location) associated with home (effective) location, item is available and the notification is sent to Remote Storage System indicating that item is expected to be stored. The status becomes Available.
   2. Duke: ("Check-in in Remote-storage"):
      1. When the item is recieved (Item scanned to refile in Caisoft) in remote-storage, it should be checked-in in primary service point of its location (as it was done for Dematic).