2020-08-06 (Kick-off meeting)

Meeting details

Agenda

• Introduction
• Overview of the main idea of the integration and connection points
• General approach discussion
  • A brief overview of the location-based approach
  • Pros & Cons of the location-based approach
  • A brief overview of the status-based approach
  • Pros & Cons of the status-based approach
  • Decide on the best approach to follow
• Accession initiation discussion
  • Accession initiation options overview
  • Decide on the accession process initiator
• Wrap-up (discuss the schedule for next meetings)

Notes

• All agreed on having several (3-4) meetings in a row - once a week. After that, there might be a break for composing a final design and have some sessions for final adjustments and approvals. Next steps - gathering on demand to discuss some non-MVP topics which might arise.
• Communication channels - mainly in slack channel remote-storage. Some topics and documents would be shared within the wiki page Remote storage integration subgroup. Private Slack chat or e-mails are also possible, of course.
• For each meeting a separate page under Remote storage integration subgroup will be created. The format will be the same: invitation information, agenda, notes, some artefacts and the list of attendees.
• In case of inability to attend the scheduled meeting, the group member should notify about that.
• The scheduled meeting is to be skipped if less than 4 SMEs are going to be present. It is proposed to mitigate the risk of missing some specific requirements and needs.
• Mary - hoping to continue with TCP/IP connection
• Tod - interested in coming out with solution where a remote storage facility (like CaiaSoft) and high-density storage facility (like Dematic) can both integrate without having a lot of specialities/forks in process
• Jacquie - we should think about multiple integrations, not an integration (single)
• Tod - Chicago has an HTTP based integration with Dematic. Tod and Mary could consider talking about a smooth switch over and compare their documentation. 
• Erin - expand integration points: any item status transition that happens onsite to a book can also happen offsite (in remote storage). Some context provided - Information on CAIASoft Item States and Item Flags
• Mary - Dematic statuses are basic: item is in or out, item is on its way and item is missing. Cammie said the same about their Caiasoft usage
• Erin, Tod and Jacquie discussed the location change in holding/item. For Tod changing location to remote can be the standard process of changing the location of the item, changing holdings location is a policy issue. For Jacquie and Erin - at Duke they change holdings location and it propagates to item location automatically.
• Jacquie - we send the materials to the location, they accession them, it's sent back to ILS and then either updates the holding record so that all items are connected to the holding at the remote storage or new holding record is created with new location and deletes the previous empty holding.
• Tod - accession originates in ILS for us. They do the updates in ILS and it goes off to the storage. So the metadata is now available and the storage facility can intake it. If there is no metadata that arrived yet then we know something has happened incorrectly. 
• Jacquie - remote storage staff accession the materials and send that pack of information to update the ILS.
• Erin - the difference between the Dematic and Caiasoft is that in Caiasoft the tray and location is assigned and Dematic dynamically puts it in the first open slot. Tod - that's optional. Mary - yes and no, you can dedicate a specific box.
• Jacquie, Mary, Tod - ILS doesn't have the information about boxes and bins. Jacquie - our special collection librarians are constantly reviewing if their materials were sent to the right part of the storage facility, they can check it on Caiasoft though.
• Erin - we would treat the entire storage facility as a unit in a FOLIO locations hierarchy. Tod - same with us, we'd treat it as a building with a bunch of virtual/logical locations underneath it.
• Erin - locations are the part of circulation rules while the request type and item statuses aren't.
• Tod - distinct request type is useful, it can initiate a different workflow.
• Erin - request types and statuses are hardcoded and aren't manageable, so the status-based approach isn't so flexible as location-based.
• Mike - it feels like a location-based approach would work for Chicago.
• Decision - to go with a location-based approach. Consider adding new request type.
• Agree on the schedule in Slack.  

Artefacts

Attendees