The Apps menu is getting rather fuller. Organizations, Finance, Orders, Invoices and Receiving have joined the native FOLIO applications available through Foundry. Lists, Claims and Circulation Log are there too, and the latest rollout adds Courses alongside User Import and Patron APIs.
That gives us more of the everyday library in one Workspace, and a useful foundation for the next questions: testing resource sharing against full FOLIO circulation, and making the same environment reproducible somewhere else.
Published on Saturday, 7 November, ahead of the Sunday weekly update. Delivery evidence closes at 15:32 GMT on 7 November; screenshots were captured that afternoon after Courses/User Import/Patron adoption. The next normal nightly rebuild, on 8 November, remains pending at this cutoff.
From supplier records to acquisitions
Last week’s update described an Organizations backend foundation. This week brings the Organizations application and Export Manager, followed by Finance, Orders, Invoices and Receiving. Those earlier storage services are being reused, rather than counted again as new applications.
The practical sequence is familiar: manage a supplier, establish funds and budgets, place an order, receive the pieces and process an invoice. That native financial workflow passed locally, including two complete resets. On Snapshot, checks covered the actual applications, their forms, linked-record pickers and Settings without creating financial records.
Lists adds query-backed record selection and export, while Claims and Acquisition Units extend the acquisitions tools. Native list refresh and CSV output, Claims email and acquisition-unit permission checks were qualified locally; the selected services and screens have reached Snapshot. A few cross-application picker labels still need tidying.
Courses and the patron services
The newest batch adds Courses, User Import and Patron. Courses supplies the native course-reserves application, linked to existing Inventory items. User Import provides batch user creation and updates; Patron provides native account, renewal and item-request APIs. The latter two are services, rather than two more entries in the Apps menu.
This batch passed native workflow and reset qualification on both Docker and Kubernetes before rollout. Hosted checks then confirmed Courses search, its create form and Settings, alongside existing applications and access denials. Existing Workspace choices, staff identity, native permissions and credentials were retained. Zitadel remains the sign-in provider.
Snapshot now has 84 active Foundry capabilities and 57 selected backend modules. The earlier 7 November normal nightly passed before this batch; the next normal rebuild of the expanded selection is still pending at our cutoff.
Choose the Workspace you need
The growing list is useful because it is selectable. KI Console provides the on-demand route: name a Workspace, choose its additional modules, review the explicit choices and implied dependencies, then confirm provisioning. Foundry resolves compatible versions and prepares the required tenant resources.
This is a way to assemble an environment for its purpose: focused development, integration work or a broader library system. Selecting an application can bring several backend providers with it. Publishing a new module does not silently add that application to every existing Workspace.
More room for ILL and DCB testing
We believe the full module set needed for live ILL testing against native FOLIO circulation is now in place. Inventory, Users, circulation, NCIP and the supporting applications give us a much more complete environment for that work.
The connected local ILL proof already completed a real borrowing and lending cycle between two institutions in one Workspace: request, supplier fill, shipment, receipt and return, with actual FOLIO loan and item effects. Live hosted testing remains the next qualification step. NCIP is currently a private evaluation integration; production machine authentication remains unfinished.
This connects directly with the OpenRS Alma-to-FOLIO resource-sharing walkthrough, which shows staff using FOLIO circulation as part of a DCB journey. The two strands are related: ISO 18626 ILL messaging and Direct Consortial Borrowing address different workflows, while both benefit from an accessible FOLIO environment in which to test their integrations.
DCB and Circulation Item backends, plus the native Circulation Log app, are now selected on Snapshot. Full DCB compliance is a priority for the next phase. Having those modules installed makes further ILL and DCB testing easier; complete external interoperability still needs its own qualification.
What was added this week
Against the 1 November weekly checkpoint, the tracked core expansion adds 14 logical backend modules and 11 native UIs, bringing its cumulative inventory to 51 backends and 23 UIs.
| New cohort since the previous weekly checkpoint | Backend modules | Native UIs |
|---|---|---|
| Optional NCIP | 1 | 0 |
| Organizations and Export Manager | 4 | 2 |
| Finance, Orders, Invoices and Receiving | 2 | 4 |
| Query Manager, Lists, Claims and Acquisition Units | 2 | 3 |
| DCB, Circulation Item and Circulation Log | 2 | 1 |
| Courses, User Import and Patron | 3 | 1 |
The core-expansion inventory excludes the existing K-Int portfolio, shared UI plugins and infrastructure. Reused providers count once. Snapshot’s 84 capabilities and 57 backends cover a different scope; neither set of numbers is a full-FOLIO completion percentage. Inventory, Import/Export, QuickMARC, Authorities and the original circulation applications were already reported last week.
Explore the dated module inventory and qualification limits
Core FOLIO expansion: 2026-11-08 · compared with 2026-11-01
Core FOLIO expansion tracked under 000134. Pre-existing K-Int suite, shared UI plugins, Foundry Admin and infrastructure are excluded from module counts. Cohorts group logical modules, not processes or complete applications.
- Hosted adoption verified: 51 backend modules, 23 frontend modules in this expansion.
| Module cohort | Previous checkpoint | This checkpoint | Coverage and limits |
|---|---|---|---|
Source Record StorageLogical module names
| Hosted adoption verified | Hosted adoption verified | Available in hosted Foundry; SRS was reported in the previous weekly post. SRS API and event integration; not a complete import application. |
Native Users and supporting servicesLogical module names
| Hosted adoption verified | Hosted adoption verified | Native Users/Settings and supporting services selected; stable actor and Zitadel retained. Supporting storage and login modules do not mean full Inventory/Circulation or replacement of Zitadel. |
Inventory and SearchLogical module names
| Hosted adoption verified | Hosted adoption verified | Inventory search, instance details and holdings verified on Snapshot. Inventory and Search agree at 37 records in the 7 November hosted readback, including the native DCB initializer record. Inventory Storage is counted under the Users foundation, not again here. |
Data ImportLogical module names
| Hosted adoption verified | Hosted adoption verified | Available on Snapshot since 26 October; local complete import proof retained. Native bibliographic import; shared plugins and infrastructure excluded from module totals. |
QuickMARCLogical module names
| Hosted adoption verified | Hosted adoption verified | Available on Snapshot since 26 October; native edit/SRS/Inventory/Search qualified locally. Bibliographic editing; native editor later reused by Authorities, not counted twice. |
Data ExportLogical module names
| Hosted adoption verified | Hosted adoption verified | Available on Snapshot since 27 October; native export-write proof local, hosted Jobs/Logs/profiles readback. Native export-write proof is local; hosted screens/readback and natural timer observations do not prove a hosted export job or production scale. |
Organizations foundationLogical module names
| Hosted adoption verified | Hosted adoption verified | Five previously reported backend foundations remain selected; Organizations, Finance and Orders applications are now counted in their separate cohorts. Foundational storage/providers counted once here, not again with their consuming applications. |
MARC AuthoritiesLogical module names
| Hosted adoption verified | Hosted adoption verified | Search, create-form/cancel and source-file Settings verified on Snapshot; local native edit/CRUD proof retained. Uses existing Entities Links/Search/QuickMARC, counted once. Local native edit/CRUD and Audit history; no hosted authority writes performed for this report. |
Calendar, Notes, Templates and AuditLogical module names
| Hosted adoption verified | Hosted adoption verified | Calendar Settings and Notes Settings verified on Snapshot; native Calendar/Notes edits, template rendering and Inventory/MARC Audit history qualified locally. Named hosted screens and local workflows only; not every shared-service feature or production-scale behavior. |
Circulation desk, requests and policiesLogical module names
| Hosted adoption verified | Hosted adoption verified | Seven backends and four UIs adopted. Requests/policy screens and native service-point access guidance verified on Snapshot; checkout/renew/request/check-in, fees/blocks and a natural notice qualified locally. Shared service-point integration subsequently adopted. No staff service-point assignment existed or was added at the hosted cutoff; no hosted checkout/check-in completion claim. Circulation Log is counted separately. mod-scheduler is not installed. |
Optional NCIP integrationLogical module names
| Not yet reported | Hosted adoption verified | Unmodified NCIP available through Console and on Snapshot; ordinary 3 November nightly and retirement follow-ups passed. Complete native two-institution ILL-to-FOLIO-NCIP peer cycle qualified locally under 000152. Private evaluation with an unauthenticated incoming boundary; production machine authentication remains separately owned. No hosted ILL peer transaction, cross-Workspace isolation or Koha certification claim. |
Organizations and Export ManagerLogical module names
| Not yet reported | Hosted adoption verified | Previously unreported Organizations completion: four native supporting providers and both UIs adopted through the normal Console path; existing apps and credentials preserved. Retained hosted adoption/read evidence, not a fresh health check or proof of every optional vendor/export integration. Earlier storage providers remain counted under Organizations foundation. |
Finance, Orders, Invoices and ReceivingLogical module names
| Not yet reported | Hosted adoption verified | Finance, Orders, Invoices and Receiving are available through Console and Snapshot. Native financial workflow and two full resets pass locally; fresh Zitadel, four app roots/forms, native pickers and Settings pass on Snapshot. Native transaction/reset proof local; hosted roots/forms/pickers/Settings verified without financial writes. Cosmetic picker labels deferred to 000154. 5 November nightly and owned superseded-runtime retirement verified; no institutional-scale claim. Existing Finance/Orders/Organizations providers counted once. |
Queries, Lists and Acquisitions toolsLogical module names
| Not yet reported | Hosted adoption verified | Native query/List refresh/CSV, Claims email and Acquisition Units forms/permission checks qualified locally. Console/Snapshot adoption and native FQM currency/locale timer callback verified after the shared routing/delegation correction. Query-builder plugin excluded from module counts. FQM deliberately uses the existing installation DB profile; native permissions and Zitadel remain. No long hosted soak or large-data/full-distribution sizing claim. |
DCB foundation and Circulation LogLogical module names
| Not yet reported | Hosted adoption verified | Both unchanged backends and native Circulation Log adopted. Normal 7 November reconstruction passed 435/435 actions; fresh Zitadel, Log read/filter, app/preservation checks passed. Native writes/reset proof remains local. External DCB-hub/ECS interoperability and full DCB compliance remain unqualified. No staff service-point assignment added. Normal channel subsequently advanced DCB during Courses adoption; predecessor retirement and 8 November nightly remain pending. Not full-distribution sizing. |
Courses, User Import and PatronLogical module names
| Not yet reported | Hosted adoption verified | Normal Console/Snapshot adoption completed 375/375 on 7 November, with 84 capabilities/57 backends. Native Courses search/create-form/cancel/Terms and existing apps verified. Courses/User Import/Patron native workflows and two resets on each substrate pass locally (Docker 562 actions; Kubernetes 784 actions). User Import/Patron are backend APIs, not separate app-menu entries. No hosted business writes or jobs. Optional Courses Fast Add and external Patron discovery authentication remain outside qualified coverage. Historical local browser timeout tracked separately. Next normal 8 November nightly and old DCB retirement pending. |
Dated evidence, not live health. Native timers, scale and whole-application completion are separate. “Hosted” describes the evidence cutoff, not every feature.
The remaining module work
Cataloguing and exchange is the established next batch. Beyond it, the remaining families will be taken in coherent groups, following their actual dependencies and useful workflows.
| Area | Remaining modules and functionality | Position |
|---|---|---|
| Cataloguing and exchange | Inventory Update, Copycat, OAI-PMH, MARC migrations, Linked Data and Linked Data Import | Next batch |
| Extended circulation | Reading Room, Remote Storage, RTAC and remaining patron-facing UI functionality | Planned |
| Bulk Edit | Bulk Operations and its UI | Deferred pending the identity-contract decision |
| Consortium | Circulation BFF, Title-Level Requests, mediated requests and consortium administration/identity contracts | Planned |
| Electronic resources | EBSCO Holdings, ERM Usage, Usage Harvester and E-usage Reports | Planned |
| Partner integrations | INN-Reach, GOBI, EBSCONET and Mosaic | With their external prerequisites |
| Shared support and reporting | Pubsub, GraphQL and Reporting | With the workflows that require them |
Bulk Edit illustrates a difficulty we have met before. Its selected implementation requires a users-keycloak API, and its user-deletion path calls that service after checking open transactions. Foundry retains Zitadel for authentication and native FOLIO application permissions, so we need to resolve that contract explicitly. We are deferring Bulk Edit while we work through the coupling, rather than treating its dependencies as settled. No replacement identity design has been selected.
The table is a planning inventory, not a final acceptance checklist. Remaining Settings, plugins, external integrations, capacity and lifecycle qualification matter alongside module presence.
Preparing to run it elsewhere
As the application set fills out, we expect to put more attention into installability and reproducibility: taking a declared selection into a greenfield environment and getting the same useful system running on someone else’s infrastructure.
The large pieces are increasingly in place—native applications, explicit module selection, lifecycle preparation, authentication and repeatable local qualification. Turning those foundations into a supported, customer-installable distribution still needs work on installation, configuration, upgrades, recovery and measured resource requirements. Console must remain optional for customer-operated installations.
The portable Workspace “suitcase” discussed last week remains a plan. Moving between providers or making a safe live-to-test clone needs complete data and file coverage, destination reconstruction and control of external effects. It is part of that operational direction, alongside the existing Backup work.
We are starting to look for partners interested in self-hosting FOLIO on-premise, especially galleries, museums and archives. We would also welcome conversations with smaller public libraries. This will not happen immediately; we are planning for it now and would like real institutional requirements to help shape the work.
If that sounds relevant to your organisation, get in touch with Knowledge Integration.