See also: FOLIO Feature Backlog (URL current as of 2018-01-04) 

Definition of Scope

(DRAFT) An Integration is a system or service, external to FOLIO, where we need to support automated data exchange between FOLIO and that external system.  The data may flow in to FOLIO from the external system, from FOLIO to the external system, or bidirectionally.  It may be transactional in nature, or it may be a bulk/batch process.  Where possible, well-known standard protocols should be used.  A spreadsheet inventorying implementing libraries' integrations is here: https://docs.google.com/spreadsheets/d/1O8orRx2dBedaeWIkbN30v2ZHyRG6BgecLXgy5xL35bQ/edit#gid=1845791394

Regular and ad hoc reporting

• we have a culture of direct database access
  • supports daily operational needs and workflows, extends functionality of LMS and allows links to other systems
    • daypass and visitor management database (see below)
    • shelf reading/inventory database
    • shelving accuracy database (QC for student shelvers)
    • Reserves pull lists (must join with Ares data)
• ability to define, code, and run custom reports that we define
• To ask other customers: how does the system help with ARL/IPEDS reporting? How do you do it?

Standards and Integrations with other systems

Roughly organized round SIGs domains.

User Management

• Integration with campus IdM
  • Flow of identities into system
  • Maintenance of identities
  • Also support identities that are not part of campus IdM
• Single Sign-on
  
  • Support for authentication federations, e.g. InCommon (U.S. Higher Ed.)
• Day pass database/access control integration
  
  • use LMS patron data to verify eligibility and provide physical access (turnstile system) and credentials for network access (RADIUS, local AD domain)
  • Relies on API or direct SQL access
• Chicago locker rental and faculty rental database which currently rely on direct access to patron information
  

Resource Management

Inventory

Acquisitions

• EDIFACT  (ordering, invoicing, claiming) 
• APIs for Real-time Acquisitions (e.g. GOBI API) 
• Patron-Driven Acqisistions
  • Patron-Driven print books from COUTTS (Cornell)
• POOF! (Cornell)
• API for financial surveillance systems (e.g. SAP)

Electronic Resource Management

• Knowledge Base for Electronic Resources (e.g. SFX)
• ERM LAS:eR 
  • ONIX-PL
    
  • OAI-PMH
  • KBART

Metadata Management

Cataloging

• OCLC integrations 
  • WorldCat Metdadata API
    • setting and deleting of holdings
    • batch cataloging, import batches of OCLC records by OCLC number
  • WorldCat Search API
    • advanced searching of WorldCat
    • used in workflows to feed OCLC numbers to Metadata API

Resource Access

• ILL & citation managers
  • Z39.50
  • ILL-Server (HBZ)
    
• ILLiad, Relais D2D (runs consortial borrowing programs UBorrow , BorrowDirect), OCLC
  • NCIP, Z39.50: four messages that need to be supported: 
    • AcceptItem
    • PatronLookUp
    • CheckOutItem
    • CheckInItem
  • ILLiad add-on pulls item info from LMS via API
• Self-check terminals and apps (MeeScan) (uses SIP2)
  
• Reserves management integration (Ares)
  • must allow the remote system to place an item on reserve and remove from reserve
  • may involve changing location, loan period, circulation status in support of this workflow
  • Course management integration (Blackboard, Canvas, LTI)
  • Ares add-on pulls item info from LMS via API
• Special Collections requisition (Aeon)

Financial Integrations

• Voucher feed to Comptroller
• Payment systems for patron charges (or integration w/ 3rd party systems)
  
  • Staff-facing for service desk payments
  • Online patron-facing for self-service
  • PCI compliant (Moneris preferred vendor)

• Export patron financial info to external systems
  • e.g. Bursar, collections agencies

Auxiliary Library Systems

• Institutional Repository
• Digital Collections/Resource Management
• Off-site storage and/or Automated Storage and Retrieval (ASR) systems
  • Export records to ASR
  • ASR updates item status in LMS
  • request items from ASR
• Rare materials (Aeon)
• Archives collections management (Archivesspace, AtoM)
  

Discovery Layer

This will include modern discovery layers such as VuFind and Blacklight

• circulation and inventory APIs will be used directly
  • UChicago driver for OLE queries the db directly in many read-only cases because OLE APIs too slow in some cases
  • Cornell does the same with Voyager APIs for same reason 
• MyAccount feature relies on VuFind to access patron data
  • VuFind needs knowledge of both campus and non-campus borrowers in LMS
  • How does authentication for MyAccount work so patron can access their data
  • Proxy borrower support?
  • Need "Patron Empowerment" APIs
• map lookups, missing items form, report a problem form request data from OLE but exist outside of VuFind. 
• some requests come in for OLE data feeds, like a feed to provide info about techbar item availability. 

Related Implementation Issues

• Security review with IT Services
• FERPA requirements for data?
• Hosted? If run locally, how does it sit in the data center? (e.g. is vendor login access required?)
• Can we run test systems for operations, integrations, and upgrades?
• Client distribution (if not web-based): are there local desktop clients that need to be used?
• For hosting, what requirements do we have for performance
• how does the system perform authority control?