Managing Unique Identifiers Across Consortia Members
Problem: Acquisitions records contain a number of human readable IDs that are expected to be unique within a given library. Some of these identifiers may also need to be unique across consortia. FOLIO needs to identify what identifiers in the Instance, Holding and Item should be unique within a member vs what should be unique across members. In order to develop this feature, we need to identify which unique IDs must be unique across the entire consortium.
See https://folio-org.atlassian.net/browse/UXPROD-4137 https://folio-org.atlassian.net/browse/UXPROD-4136
Use Cases
Case 1
Identifier must (or should) be globally unique - requires validation against all tenants
All tenants share "ownership" of this identifier
Requires error handling and/or manual tenant assignment in the event of duplicates
Case 2
Identifier must be accessible and usable by all tenants, but with localization allowed
All tenants use this identifier, but this identifier can be tailored per tenant
Uniqueness can be achieved via prefix. suffix or other internal handling
Case 3
Identifier must be visible to all or specific tenants, but editable only by the owning tenant
Uniqueness can be achieved via prefix, suffix or other internal handling
Case 4
Does not need to be unique
Disambiguation options
Rec Type | ID | Editable? | Global/Local | Why unique? | Explicit or augmented? | System-generated or manual? | Responsible Team | JIRA Link | Use Case | Notes |
|---|---|---|---|---|---|---|---|---|---|---|
Tenant | Name | Y | G |
| E | M | Thunderjet |
|
| Done |
Tenant | Code | ? | G |
| E | M | Thunderjet |
| Tenant Code is intended as a prefix to enforce identifier uniqueness across multiple tenants (e.g. prepending to an acquisition unit to ensure uniqueness across the consortium) | |
Item | Barcode | Y | G | Resource sharing | Augmented | M | Folijet Spitfire |
|
| Nearly impossible to eliminate barcode duplication across a large consortium, but need to differentiate ownership. |
Item | Item | N |
|
|
|
| Folijet Spitfire |
|
| Even if not unique, do we need some sort of indicator of which tenant the Item HRID belongs to? |
Instance | Instance HRID | N |
|
|
|
| Folijet Spitfire |
|
| Even if not unique, do we need some sort of indicator of which tenant the Instance HRID belongs to? |
Holdings | Holdings HRID | N |
|
|
|
| Folijet Spitfire |
|
| Even if not unique, do we need some sort of indicator of which tenant the Holdings HRID belongs to? |
Organization | Code |
| L |
|
|
| Thunderjet | 2 |
| |
Organization | Name |
| L |
|
|
| Thunderjet | 2 |
| |
Orders | PO Number |
| G L |
|
|
| Thunderjet | 3 |
| |
Orders | PO Line |
| G L |
|
|
| Thunderjet |
| 3 | I can't identify any scenarios where Tenant A would need to see a unique POL for Tenant B |
Invoices | Invoice # |
| L |
|
|
| Thunderjet |
| 3 |
|
Acquisition Unit | Name |
| G | Shared order across multiple tenants | Augmented | M | Thunderjet | 1 | Possible use case: central tenant acquires on behalf of other tenants. | |
Fiscal Year | Name |
| L |
|
|
| Thunderjet |
| 3 |
|
Fiscal Year | Code |
| L |
|
|
| Thunderjet |
| 3 | Presumptive. Need confirmation from consortia. |
Ledger | Code |
| L |
|
|
| Thunderjet |
| 3 |
|
Group | Code |
| L |
|
|
| Thunderjet |
| 3 |
|
Fund | Code |
| L |
|
|
| Thunderjet |
| 3 |
|
Voucher | Number |
| L |
|
|
| Thunderjet |
| 3 |
|
User | Username | Y | G | Users can have multiple affiliations; need to avoid conflict. | Explicit | M | Thunderjet | 1 | Use case: Central office has a John Doe with limited permissions across multiple tenants. One of those tenants has a staff member Jane Doe. Folio cannot support 2 "jdoe" logins within the same instance. | |
User | Barcode | Y | G |
|
| M |
|
|
|
|
Service point |
|
|
|
|
|
|
| For additional info please refer to https://folio-org.atlassian.net/browse/UXPROD-2367 |
|
|
User | External system ID |
|
| The external system ID for the User. The field is auto-populated if it is included in source data provided by an external system. |
| Auto-populated data in source data provided by external system |
|
|
|
Processes Potentially Affected
General
Staff/user management
If another record type's number is stored in a given app or record, how does that affect the storing app/record if the owning app/record changes the number or number structure, e.g.
Inventory Instance doesn't know which SRS MARC ID it's related to, but SRS MARC record knows which Instance UUID it's related to
Inventory Instance links to the SRS MARC and allows for quickMARC lookup/edit/update SRS MARC/update Instance, based on that relationship
Inventory Instance/Holdings/Items do not know which POL(s) they are related to, but each POL knows every Instance/Holdings/Item related to it
Inventory displays POL info in the Instance/Holdings/Item
Circulation
CI/CO
Requests
Loans
Fines/Fees
Users
Acquisitions
Collaborative collection development (view-only)
Joint orders (possibly - may be out of scope. Potentially impacts single-tenant, multi-acquisition unit sites more.)
Cataloging/Inventory
Close association between Instance HRID and SRS
Data Import
Most important matchpoints for Data Import:
SRS MARC Bib: 001, 010, 035, 9xx fields, 999 ff
SRS MARC Authority: 001, 010
Inventory Instance: HRID, UUID, OCLC number, LCCN, Other local ID, POL, VRN
Inventory Holdings: HRID, UUID, Perm loc, URI, POL, VRN
Inventory Item: HRID, UUID, Barcode, POL, VRN
Proposed Workflow
Questions
Question | Status | Conclusions | Comments |
|---|---|---|---|
Are any record types or unique identifiers missing in the above list, which will need to be visible or partially visible to some or all consortia members? | open |
|
|
Are there any circumstances under which other order-specific information should be shared with the consortium? | open |
|
|
Do IDs need to be natively unique or can they be augmented into uniqueness? |
|
|
|
Why do we need uniqueness on a per record basis? |
|
|
|
When is it OK to duplicate an ID? |
|
|
|
Cross-consortia/multi-consortia uniqueness? (Consortium-to-consortium) |
|
|
|