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 - UXPROD-4137Getting issue details... STATUS - UXPROD-4136Getting issue details... STATUS
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 | Thunderjet | 3 | |||||||
Orders | PO Line | 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 | ||||||||||
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
- 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
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) |