2026-05-20 Data Import SIG Meeting

Item

Announcements

Trillium bugfest - Slack channel #folio-bug-fest / Bug Fest R1 2026 Trillium - Non-ECS - Eureka

New topic: Set for delete: Should users be able to match on deleted records in Data Import? - To be discussed at June 3rd meeting.

PC had a discussion about SIG scope and priorities. Ours is split between development and supporting the user community. It’s hard to keep all of this running. We’ll have this discussion about our work for the SIG.

Bugfest: No updates

WOLFcon 2026: Preconference sessions have been posted and registration is open.

May 20, 2026: Updates on new functionality and bugs:

Update instance, holdings, and item in reverse order (Line 6 in New Topics spreadsheet.)

https://folio-org.atlassian.net/browse/MODDATAIMP-1290 / https://folio-org.atlassian.net/browse/MODINVSTOR-1363

@Ryan Taylor Would it be possible to get updates on these tickets (and for 1363 how redundancy works and any documentation)? Ryan might create a Spike for this work to update in reverse order.

For 1363, the dev team is still actively looking into this. The team wants to understand what the goals are, documentation and how this works, if there are implications to other functions, and how to make this work so it doesn’t interfere with SME’s work.

In last week’s conversation, we talked about consistency between quickMARC, bulk edit, and data import. For example, if you edit a marc srs in quickMARC to add a field that isn’t mapped to the instance, then the version history of the instance doesn’t have any new items but the update date time stamp is updated for the instance. In the beginning, we were told that any update to a marc srs triggers an update to the instance and vice versa. If we break this relationship, then we have to work through the implications of this. There are 2 logics at the same time - technical logic and workflow logic. What is the instance and its role? This falls under the scope of MM. Initially it was meant to be a summary and then it changed. There are institutions that don’t use MARC. This change was unexpected. With time to understand the intention, the behavior might be fine with more information is provided and people can understand how this affects their workflows. We need to talk about the logs and the update dates. People need to know what is happening at the backend and have understandable log. From chat: going forward if the srs and instance are separate there should be the update date for both in the administrative data. This is a great idea.

Action item: Christie and Jennifer will contact MM SIG to have discussion there.

Housekeeping

Develop https://folio-org.atlassian.net/browse/UXPROD-4080 Created in 2023.

Developers need SME use cases and examples.

Current Examples in this Jira as of Apr 22, 2026 :

• Example 1: Incoming MARC Bib only has Leader, 245, 856. Library only wants to update the existing 856, but not replace the rest of the existing MARC Bib

• Example 2: only add the OCLC 035 to the existing record; ignore the rest of the incoming record{*}{*}

See Jira ticket for comments. @Ryan Taylor Is this enough info for the developers?

See Jira issue for link to mockups (UXPROD-4080). Ryan found our comments very helpful. Worked with Kimi on mockups and dev lead on estimates.

We have 5 actions to trigger a specific behavior. Some language was adjusted to ensure consistency. Actions: Add, Add if not duplicate, Delete, Find and Replace, Replace. Question about validation: Is this a phase 2? If we don’t have this validation, then it has to be clear what happens for each action. If it is a non repeatable field, would the add replace? It shouldn’t be a large task to add verbage and a quick check on non repeatable fields.

Q: If it a non repeatable field, you couldn’t add it at all? There might be a scenario where there are 2 100 MARC fields, then you couldn’t use the add action. Yes you would need to use replace. This could work but the language needs to be very clear. If someone adds a non repeatable field, would this create a corrupted record or trigger failures? @Ryan Taylor will check backend validation for this behavior.

Replace is how it works today. It is a full over write of the field.

Delete: will delete remove everything? yes this will remove everything.

Find and remove: Looking for a value and would require a data field. Could we do a “not” as in delete everything that is not a 856 from Gale? This is good info. Perhaps we could mimic match profiles. Could this be combined with Delete? The value field and operators, this should be separate.

We will have a quick recap in the June 3rd meeting.

Discussion

Open questions?

Roadmap Discussion (At same time of a new release)

MVP Discussion (at the same time of a new release)