FOLIO tenant configurations

For OpenRS to produce expected results in FOLIO, each FOLIO tenant needs the following settings. Those labelled "Auto" are autocreated when the tenant is enabled for DCB (enablement requirements in ticket US1331136).

Type	Role	Usage	manual or auto creation	Examples
Patron Groups	supplier	Used at the supplying library to identify the borrowing patron group. Virtual patron records are automatically generated via FOLIO DCB API in the supplying library when a request is created by OpenRS. Virtual patron groups are used in circulation rules when the item is loaned to the virtual patron. A loan to the virtual patron results from a checkout to the patron at the borrowing library. Patron group mapping is configured via DCB Admin Module to see how patron group mapping works. Tim Auger	Manual	https://mobius.folio.ebsco.com/settings/users/groups
Material Types	borrower	Used at the borrowing library to identify the supplier material type. Virtual item records are automatically generated via FOLIO DCB API in the borrowing library when a request is created by OpenRS. Virtual material types are used in circulation rules when the item is loan to the patron. A loan to the patron results in a checkout ot the patron at the borrowing library. Material type mapping is configured via DCB Admin Module to see how material type mapping works. Tim Auger	Manual	https://mobius.folio.ebsco.com/settings/inventory/materialtypes
Circulation Rules	supplier and borrower	Used when supplying and borrowing. The syntax for each are as follows: supplier (lending) role virtual patron group(s) \| local material type or loan type \| effective location (optional) loan policy (loan period should be inclusive of transit time; you may want to build into supplier side loan policy a few days for transport back to the supplying library. When the item is checked out to the patron, OpenRS will checkout the item to the virtual patron in the supplier system. Adding transit days to a supplier loan policy will set expectations for users seeking to obtain the item.) request policy (no recalls) no patron notices no fees/fines borrowing role Local patron group(s) \| virtual material type(s) \| location "DCB" (all virtual item records contain this location) loan policy (loan period should be inclusive of transit time) request policy (no pages, no recalls) patron notices fees/fines pickup role (as borrower at non-borrower pickup location) virtual patron group(s) \| virtual material type(s) \| "DCB" (all virtual item records contain this location) loan policy, request policy (no recalls) no patron notices, no fees/fines	Manual	https://mobius.folio.ebsco.com/settings/circulation/rules https://gil.folio.ebsco.com/settings/circulation/rules
Staff slips	all	FOLIO DCB uses the same staff slips as FOLIO circulation staff slips. The requestservicePointPickup token is used to print the dcb pickup service point (see above) associated with the request.	Manual	https://mobius.folio.ebsco.com/settings/circulation/staffslips/8812bae1-2738-442c-bc20-fe4bb38a11f8
Service Points	supplier	These service points are created automatically by the FOLIO supplier when it receives an incoming DCB request. Represents the pickup location of a member library. Prints on staff pick slips for operational purposes.	Auto	https://mobius.folio.ebsco.com/settings/tenant-settings/servicePoints
Location	all	The location "DCB" is automatically created by FOLIO when the tenant is enabled for OpenRS. This location is defined at each level of the FOLIO location hierarchy: DCB institution DCB campus DCB library DCB location	Auto
DCB calendar	all	A DCB calendar is automatically created by FOLIO when the tenant is enabled for OpenRS. As part of the enabling process, each dcb service point is linked to the DCB calendar. Latest changes can be found here: MODDCB-119 - Getting issue details... STATUS Tim Auger	Auto	https://gil.folio.ebsco.com/settings/calendar/all/b69a5516-e382-4764-a685-095ae9a050f9
DCB instance record + holding	borrower	The DCB umbrella instance + holding record is automatically created by FOLIO when the tenant is enabled for OpenRS. This allows for FOLIO to leverage the necessary architecture to allow for all DCB functionality to integrate seamlessly in FOLIO.	Auto
DCB loan type		The DCB loan type is automatically created by FOLIO when the tenant is enabled for OpenRS.	Auto	https://gil.folio.ebsco.com/settings/inventory/loantypes
DCB cancellation reason		The DCB cancellation reason is automatically created by FOLIO when the tenant is enabled for OpenRS.	Auto	https://gil.folio.ebsco.com/settings/circulation/cancellation-reasons

Requests

Request in Locate DCB

Action	Notes	Screens
View Instance detail screen	Status is always "Available" or "Unavailable". Currently, this approximates whether or not the item can be requested but it's not a perfect overlap. This needs both definition and reconciliation. A document that elaborates on the display behavior for instances and items in the DCB union catalog can be found here.
Patron authentication	Patrons have two paths to authenticate in OpenRS. 1) Select the avatar at upper right where the user will be prompted to sign-in or 2) Click "place hold" beneath the instance title. In both cases, if the patron has not already authenticated in the current browser session, they will be prompted for their institutional affiliation. From there, they will be prompted for their credentials. OpenRS supports both SSL and native ILS authentication (e.g. barcode and PIN). Authentication and patron record lookups are always performed against the ILS/LMS. No patron data is stored in DCB.
Place hold	After authenticating, the patron is prompted to select a pickup location and then click "place hold". After that, you will see a spinning circle as, in the background, DCB executes RTAC again to acquire the latest item state information from the ILS/LMS. A document that elaborates on the behavior for instances and items in the DCB union catalog can be found here.
Hold placed		**Need hold results screens here.

Request in FOLIO

Action	Notes	Screens
Supplier request	As the supplier, the Requests app is where to start. All DCB transactions use request type "page" and requester name "DcbSystem, undefined." The requester barcode, however, is specific to the patron library. This acts as the unique identifier for staff to communicate with borrowing library patrons when circulation exceptions occur (e.g. lost book). OpenRS (a.k.a virtual) patron groups are the same in every FOLIO tenant, and there are corresponding patron groups in every member library ILS/LMS. Regardless of the type of ILS/LMS, the DCB performs the mapping to translate equivalents to each library. (See mappings under the DCB Admin section below.) All pickup locations at other member libraries are represented as "Pickup service points". These can be referred to as "virtual" service points since these pickup locations are derived from the borrowing library. These are generated on-the-fly when that pickup location is newly introduced to a tenant, then reused for subsequent requests for that virtual pickup location. These service points will automatically link to the default DCB calendar.
Virtual patron	The DcbSystem patron is intentionally thin compared to a local patron. The user type, which is "dcb", is autocreated by FOLIO. This connotes a special meaning and handling of the record (which is not editable or searchable).
Borrower request	As a FOLIO borrower, OpenRS/DCB requests are associated with the borrowing patron. They can see and cancel OpenRS requests in Locate, as well as see checked out items and initiate renewals from the bookshelf feature.
Virtual item

DCB Admin

The DCB admin module is available to Consortium Central Office, EBSCO, and K-Int staff for on-boarding and support activities.

DCB admin STAGING for MOBIUS: https://libraries-dcb-hub-admin-scaffold-uat-git-staging-knowint.vercel.app/en-US

DBC admin TEST for Galileo: https://libraries-dcb-hub-admin-scaffold-uat-git-galileotest-knowint.vercel.app/

The "Requests" mode contains access to the lifecycle of all DCB transactions.
- This is a request and circulation troubleshooting tool for implementation and support staff.
The remainder of the modes allow implementation specialists to define the systems and their agencies and corresponding shelving locations and pickup locations.
There are also mappings for patron groups, material types and pickup locations to canonical DCB values.
- Example: FOLIO patron group value "undergrad" is mapped to DCB canonical value "200"
The "Libraries" mode contains the Settings area where a library can be enabled/disabled for supplying and borrowing.

Mode	Screenshots
Requests
Audit	--
Mappings
Libraries

FOLIO Implementation Q&A

	Question	Answer	Notes
1.	OpenRS will create a virtual patron record for a specific patron in the borrowing FOLIO member tenant, without identifiable information. Will these be identified with a user type of “shadow,” or is that reserved for staff accounts? (Or maybe “system”?)	Not shadow accounts but "DCB" patrons with a very limited amount of data (DCB Patron Group, DCB Patron Barcode, DCB Library Code (aka agency code), DCB Transaction UUID). For more details on the relationship between entities, see the "Entity Relationship Diagram" section in DCB Integration.	No configuration needed. Automatically generated. Demo when Polaris/Sierra libraries are involved
2.	Only the borrowing patron should receive patron notices. Is the library aware of the possibility of customizing notices for OpenRS borrowing?	Important note – there is only one version of each type of staff slip. They can customize these notices as needed for OpenRS borrowing.
3.	Each FOLIO member tenant should have a location representing each other member library, under the DCB institution hierarchy. This needs to exist before circulation rules referencing those locations can be created. Who will create the locations in each member tenant?	I would assume central consortium office since they have the keys to the kingdom and/or a trusted delegate.	Need to confirm with central consortium office that they can create locations. Can we automate?
4.	Each FOLIO member tenant will need standard policies (loan, overdue fine, lost item fee, patron notice, request) created for each loan period for OpenRS transactions. Has central consortium office determined what these policies should contain? Who will create the 5 policies in each member tenant?	Central consortium office would either do it themselves or assign it to their member libraries.	Need to confirm with central consortium office that they can create loan policies
5.	FOLIO allows the use of multiple locations as criteria (connected with an implied “OR”) in a single circulation rule. Once the location records exist in a FOLIO member tenant, a shared list of locations can be pasted into each tenant’s circulation rules, followed by removing that site’s location from the list. Who will create the circulation rules for lending (at least one per different loan period) in each member tenant? (The patron notice policy for lending transactions will not be set to send notices.)	I was planning to create a template and then have central consortium office figure out how they want to populate in each system.
6.	Every FOLIO member tenant needs patron groups along the lines of “OpenRS long” and “OpenRS short.” Who decides how these will be named? Who will create them? When will we know if central consortium office has approved this smaller number of loan periods than what they were hoping for?	Central consortium office should decide.
7.	The circulation rules for borrowing in each FOLIO member tenant will use the borrowing library’s existing patron groups, in conjunction with an OpenRS location, to apply the appropriate sets of circulation policies. Who will create the circulation policies and circulation rules for borrowing in each member tenant?	I'll create a template for the circ rules and then they can modify to suit their needs and copy into circ rules. It would be ideal if this process (and above processes) followed the standard FOLIO process.
8.	Each FOLIO member tenant’s circulation rules will need careful review to ensure that the combination of priority row, criteria used, and order of rule lines applies the OpenRS policies to the appropriate transactions. Who will do this review?	Great question. I will volunteer for manual inspection duties.
9.	An OpenRS service point specific to the lending library will be created automatically in the borrowing library’s member tenant. If FOLIO allows circulation transactions to happen without a calendar assigned to the corresponding service point, then OpenRS can simply approximate the calendar’s function by padding due dates (e.g., a 7-day loan might actually be given 10 days). Who will notify central consortium office of this functionality workaround?	No, there must be a valid calendar assigned to the service point to create a loan transaction there.
10.	Are DCB transactions written to CIRCLOG?	Yes.	See UICIRCLOG-140 - Getting issue details... STATUS . More details forthcoming.
11.	What is this product called?	OpenRS DCB. OpenRS is the project name. DCB is a model of Resource Sharing and the first piece of the OpenRS resource sharing portfolio.
12.	Where are virtual item records stored in DCB? Is there an API to retrieve/view these records?	There are no virtual records stored in the DCB hub. Those are only stored in the individual FOLIO tenants. DCB manages the the synchronization of virtual records between systems based on the state of the request and the loan. There is an API accessible to DCB but not elsewhere. There isn't a way to access them [yet] via other tools, minus direct SQL against FOLIO DCB-specific inventory. This is where the virtual transactions are stored, not in FOLIO inventory, so any standard tooling would need to be adapted to access DCB transactions.
13.	Just to clarify, if a library loads something locally and chooses not to include in the central tenant, can it still appear in OpenRs?	Yes. DCB is harvesting from the individual tenants via OAI-PMH.

Browser not supported