this idea was accepted more than three years ago. Unfortunately, we are still waiting for implementation. Can you tell us when it will be implemented?

Is there a timeline when this useful functionality wil be released? It's "accepted" for 10 months now.

Is this functionality due for release imminently?

I would like to be able to set how many days after the user has expired before they get purged. During the summer if students have not registered for the fall they could get purged and you have lost the circ desk ability to easily review their history. So either being able to say 5 days or 30 days or xx days after expiry would be helpful.

When creating the linked accounts, it is possible to use the Linked Account Rules to set a purge date to all linked accounts. This way, the automatic job (once developed) will always try to purge the linked accounts, because of their purge date, and will keep only those records that have liabilities that prevent their purging.

My comment below originated as a separate Idea Exchange post, and it has been combined into this other Idea Exchange post, I assume by Ex Libris.

I do not think the two topics are the same, and I am not sure they should have been combined.

I am advocating for a job that can look at "empty" linked user records, aka, linked user records where the purge date may still be in the future, but, where the user record no longer has an active transaction.

The idea this was rolled into was asking for a way to schedule a purge job to run automatically, based on that purge date. This idea that it was rolled into is also making no distinction between local and linked user records.

Please note: If these two separate ideas can be solved in development at the same time, then it is okay to combine them into this one idea. But I do not want my original intention of my post to be lost within this combination.

I wholeheartedly support Debbie's suggestion. As a reference librarian in a CARLI library assisting patrons to understand the information regarding requests and checked out items, I can verify from personal experience that "Patrons are...confused as to why a library would still be listed on their account, when they have no current activity at that other institution."

The unnecessarily long list also compounds confusion caused by the need to click on successive institution names to see what is listed under each one individually. The longer the institution list is, the more opaque the account information becomes to patrons. We've had questions from many who after signing in cannot find the checkout record for a book they actually have in hand and want to renew.

In Alma, Linked User records saved to another institutions IZ as part of a collaborative network are eligible for deletion following the same parameters as that IZ's home patron records:
1) Linked users can be manually deleted in Alma; statistics are not maintained.
2) Linked users can be purged using the Alma purge job; the criteria is the patron record's purge date.

Alma is making the assumption that the user at Institution A will perpetually (as long as the user is an active/eligible user at Institution A) want to maintain their linked user accounts in all other instititions that are a part of the collaborative network (Institutions B - infinity).

This causes issues in large consortia using Alma collaborative networks:
1) Patron Identifiable Information is being maintained in the collaborative network IZs (outside the patron's home institution) for longer than is needed for transactions.
2) While Primo VE now contains an "activity" indicator to show a patron that they have a transaction with another institution, the overall list of institutions where the patron's record is maintained can be too long to be manageable. Patrons are also confused as to why a library would still be listed on their account, when they have no current activity at that other institution.

In our previous system, Voyager, there was a Circulation server job that was set to automatically "Purge Universal Borrowing (UB) Patron Stub Records (Circjob 29)" (aka- Collaborative Network Linked User Records) after the record was no longer in use by a transaction at the institution. We ran the job every night.
https://knowledge.exlibrisgroup.com/@api/deki/files/77521/Technical.pdf?revision=1

The server job would identify linked user records and then check for the existence of fines/fees, holds, reqeusts, charged/checked out, or lost materials. If the system job found that the linked user record was "empty" aka, had no active transactions at the institution that should be used to prevent the record from deletion, the job would automatically purge the linked user record. The job did NOT delete a linked user record if it was still in use by a transaction. The server job retained the patron's statistics for reporting purposes, but the purge served to allow anonymization.

Please add a scheduled "purge empty linked user records" job to Alma that can be scheduled by each institution. Ideally, it should offer the institution the ability to select to run the job daily, weekly, monthly, or yearly.

Having this as a scheduled job would definitely be a useful and sensible feature!