Skip FOLIO Project Navigation

đź•Ą Change tracker app, UX iteration 1


I agree that a change tracker would be very useful in the world of circ transactions. I’ve always wished for an item status tracker, and it sounds like this tracker could be used for that. Showing the full date/time and operator ID would be very useful. Q: Would the tracker capture system-initiated changes (such as batch job record updates), or just operator-initiated changes? it would be useful to capture everything, and be filterable by date range or opid.


This looks like a great and very helpful feature! How about tracking automated changes too? Automated fees and fines are often questioned by patrons and a complete history of events and related fines would be very helpful.

Still privacy rules have to be taken care of… So perhaps when a “case” is done, patron information has to be anonymized/removed in historic records too.


I share @PaulaSullenger’s concerns. But I also think this functionality, if it can work, would be amazing. We currently use so many local notes that attempt (somewhat ineffectively) to do this. Would it be possible to select only certain types of changes to track? Or to periodically purge certain types of changes only?


Great point @schwill! I didn’t think about privacy. Do you have an idea of other fields that could have a privacy issue?
And yes, in our vision, not only manual changes will be tracked but automated changes as well :slight_smile:


Thanks for your comment @ecboettcher @Joanne_Leary @taniafersenheim. We would like the change tracker app to automatically track every type of fields and changes (manual and automated). In our vision, users would be able to sort changes via the following filters: app name, category (made by the team, by you or automated), date range, keywords. @LauraW Are we missing a filter? What do you mean by types of changes? Could you give me an example?


An example of something we might not want to track (or might want to purge routinely) would be yearly resets of circ data. We might also want to purge acquisitions receiving changes after the end of a fiscal year.


I wonder where it is best to take care of privacy issues of records. Perhaps the app storing the record is the best place. If so, it should take care of the record history too. That way the tracker app could just display what is left after anonymization/pseudonymization/deletion…


If it is feasible, then i say do it! Currently Aleph retains all changes to item and order records, and a log of time/users who make changes to bib and holdings records (but not what the actual change was). I don’t know that we need to retain all the text that was changed, for example in a bib record, but knowing what element in an item or order for example is super helpful.


@Stephanie another filter to consider: by type of record, since there may be multiple record types within a particular app. Date range (which you already mentioned) will also be a useful one. Thank you!


Coming back to this late, sorry - some other information that could be helpful to have would be the service point where the change was applied (e.g., to track down an in transit item that hasn’t arrived), the time (not just the date) of the change, or links to loans it’s been part of. (Some institutions that keep borrower history want to be able to get to the previous borrower for the item, for example.) Are those sorts of things out of scope for this app, or no? The last might be similar to what @taniafersenheim is saying for seeing whether the item has filled a request, but I’m not sure.

I’m particularly interested in the “scrollable table with recent changes related to Rosalyn Roman” in the fourth screenshot above. Does that only refer to the changes the user is presently making, or all changes in a certain time period? If the former, is there a way to see all the changes to an item record, starting from that item record? Or is it that you have to go into change tracker & search for your item?


Great feedback! Thank you @ecboettcher! For the scrollable table, it is only for changes presently made. If a user would like to see the change history of Rosalyn Roman record in the Users app, he would have to open the Change tracker app, select the Users app in the filters and type Rosalyn Roman in the search field (see 5th screenshot). So yes, users would have to open the change tracker app to search records and see the changes.


Thanks for clarifying! Reviewing this again, I realized I had lost sight of the first screenshot at the top - the rightmost pane looks like it shows all changes for a particular record within the Users app, without going into the Change Tracker and filtering/searching for the specific record. So are there two ways to see all changes for record X? Or is the thinking now that opening the full Change Tracker app is the only way?


My last replied was a bit confusing, let me rephrase it. To see all changes for record X, you could either click on the change tracker icon of record X or open the Change tracker app and look for this record.

The difference between both is that via the Change tracker app, users could easily see changes history for a specific field at a glance. For instance, if you look at the last wireframe, the status field of Rosalyn Roman has been selected and on the rightmost pane, you can see all changes related to this field only.

Will it make sense for you?


Hello guys @ecboettcher @Ann-Marie @Jessica @schwill @LauraW @Joanne_Leary @taniafersenheim @PaulaSullenger! Based on all your feedback, it looks like librarians shall be able to choose which fields shall be tracked to fit all workflows and address privacy issues. To do so, we could add the change tracker as a setting option for each app and allow users to unselect tracked fields. The wireframe below is an example of the Users app settings with the change tracker option selected.

Please let me know if this idea could address privacy issues and make the app more useful for all.


Hi Stephanie,

this is an interesting approach on reducing the information stored. The wireframe does not show “date of change” and “sourc of change (user XY, automatic etc.)”. Both are helpful with regard to qualtity management, but in some cases unions may raise their voice here too. So providing a checkbox for them too could help different institiutions (with different unions) to make their local choice.

From a GDPR point of view it can be really helpful to reduce the historical data using the checkbox-approch. Still I assume that “deleting” historical data also is quite relevant. Deletion could be

  • time driven: remove patron information from loan record after 2 weeks - necessary to follow up on damaged items returned via automatic RFID shelves
  • event driven: patron (lawfully) requests deletion
  • or a combination of both: delete inactive patrons after two years, if there are no open loans…

Perhaps each app using “change tracker” knows best when to delete it’s current and historic records. Does this look like an API that “change tracker” could provide for other apps with complex data management like a loan app?


Thank you for your great feedback! I will look for a way to manage automatic data deletion based on a time range and/or events.

I am not sure I fully understood your comment about “date of change” and “source of change”. These two information are shown in the Change tracker and User apps wireframes. Users could search for a specific record based on the date and source of change.

Could you give me an example showing why those two data could be useful in the change tracker settings page?


Hi @Stephanie, some unions (=Gewerkschaften, Personalräte=staff council, Betriebsräte=workers council) are concerned with “performance monitoring” of staff. Here the result can be, that it is (locally) forbidden. So tracking staff activity (item, staff-id, timestamp) openly might not be an option. Disableing it’s recording can be a remedy or perhaps “read-protection” for normal mangers/users. In rare and specific cases it might be permissable to search this data perhaps “under the eyes” of a staff council member…


“Some” would be all here in Marburg University :wink: Performance monitoring or something similar would definitely challenge our “Personalrat”, the staff and the “Datenschutzbeauftragter” (Data Protection Officer). Hesse was the first German state that introduced a general Data Protection Officer and still has the toughest rules here. Perhaps this can help our colleagues :slight_smile: [].


If the tracking feature could be turned off, would that satisfy the “staff monitoring” rules at certain institutions? Some of us would like to have this available, especially when FOLIO is new. Something goes wrong, how can you track the problem if you can’t see who has done what? Is there a problem with a person, or with a poorly designed process? For me, staff monitoring isn’t for punitive purposes.


From a professional point of view I absolutely agree with you Paula :slight_smile: Perhaps I should go back to 1993/94 when Hesse introduced OCLC LBS (the first ILS ever here): when we realized that some kind of staff monitoring would be possible in RA/circulation both sides (aka directors/staff/staff council) decided that only … well … anonymous/general/impersonal accounts would be allowed. This means that the staff at the counter uses the same neutral account at all work stations. Of course this doesn’t make sense in acquisition/resource management where we have more specialized accounts. - I - can do some tracking and staff monitoring at circulation/RA of LBS (and really need it) but to this day I’m not allowed to create personal accounts for the staff at our lending department. It’s probably a very German thing to exclude the possibility that tracking isn’t for punitive purposes as we have a history here. But - and this is our common issue: we’ll need some proper tracking and when it’s controlled by systems librarians/systems managers in a clear defined frame everything will be fine :slight_smile: (… we even had to drop the names at the library cards a few years ago here in Marburg and our students council still prevents the introduction of a students ticket that could be read via QR tag, RFID or barcode …)