Can we please check on the status of this one. It looks like it was accepted in 2018. It would help a great deal to comply with GDPR and personal data retention agreements.

Hi,

Wondered if we could chase this for an indicative quarterly/half year release plan. It would make auditability (and use of Analytics in set creation) much more manageable than the current limited purge criteria, and also maybe benefit job size if that helps address comments on the number of records/length of job run concerned.

To add my own use case to the mix (and sense of urgency): We need the granularity afforded by sets to give us more control over which records are purged. Our accounting office requires us to produce information about fines/fees for a set number of years after they've closed, and the standard checks for active fines for purging a user isn't good enough.

I agree with the others, this would be a very helpful enhancement. It's a terrible experience to set parameters for a purge without being able to see what the results are, and then kick it off knowing that only *after* the job completes will you be able to see if you purged the right people.

Lots of people can run sets without the ability to do a mass purge, so this enhancement would also mean that another staff member could figure out who they wanted purged, create a set, and then just ask the User Administrator to purge based on that.

What is the status of this planned enhancement? The last update to this item was October of 2018

This would be really useful. As we have a lot of different user groups and campuses, that need to be purged at different times. It would be good to get an update.

When is this to be implemented? I've been sitting all day running purge jobs in Alma. It takes forever. After 10 hours I've been able to purge almost 4000, out of almost 14000. This is not good enough. We really do need something that runs faster. Please, Ann-Louise

Hi Moshe,
Is there an update on this 'planned' feature?

Thanks,

Sam

Thank you, Moshe!

I believe both ideas here should be developed. Granularity on the user purge job, and adding a user delete job.
GDPR is just the latest reason why we should be concerned about how we handle user data in Alma. This has been a concern in Alma prior to the GDPR as well.

Ann-Louise Skjager, Oslo metropolitan university

Agreed. Alternatively, it would also be helpful to have the Purge User job in the list of Scheduled Jobs. This would make things so easy for libraries concerned by the GDPR

Hi ritu - yes, it’s possible already to change the user group and then purge that whole group, but then you lose the ability to report meaningfully on data in Analytics. The argument for giving more options for the purge job is that we shouldn’t have to essentially corrupt our data in Analytics just to remove user accounts from Alma.
Cheers, Stacey van Groll, University of Queensland

An alternative I would suggest that you create a user group something like Purge_2018 and change User group to this newly created group for a set of users that you want to purge.
But yes, it would be useful if we have more granularity on Purge job.

That would be great and we strongly support this suggestion. There is a thread in the Alma Mailing List - having subject [ALMA-L] Purging Users - about it. The thread shows clearly how lack of this feature is perceived as a problem by many users. GPDR in Europe makes the need of this feature even more urgent for European Customers.