This seems like basic functionality, please implement asap.

Hi Liza - you have asked on July 20th 2025 for a list of specific jobs. Please see the comment from two years ago on July 23rd 2023 which has a spreadsheet link containing several jobs.

We would really appreciate more detail in which records failed / were no accepted in a publishing job so that we can investigate and fix them.

Hi all,
As the upgrade of the jobs to the new UI is not on the roadmap for the next year, we would like to ask what specific jobs require those details?
As some specific Alma jobs already include failed records information.

Almost two years have passed since this idea got accepted but apart from letting the Alma Working Group set up a list with names of specific jobs seen as eligible for this "enhancement" nothing happened?

Just reporting the number of errors without any hint on which of the processed records raised these errors IMHO is simply useless and therefore a serious design bug that has to be fixed by the software vendor for **all** jobs affected by the bug. There is absolutely no need for the community to prioritize certain of these jobs or to vote for which of them only the bug should be fixed. I mean we are not talking of any fancy nice-to-haves here. This idea asks for nothing more than adhering to the most basic rule of logging errors: If you process an object and an error occurs then log the ID of the object together with the reason that caused the failure.

The AlmaWG is compiling a list of jobs for ExLibris to focus on with regards to this Idea.

The four jobs mentioned in the comments to this Idea have been added to the spreadsheet (Filter Set by Indication; Publish to OCLC; Discovery Import Profile; Synchronize Users).

If you have any of other jobs that you would like added to this list please add them to this google sheet (https://docs.google.com/spreadsheets/d/1bDf6HgUTZIsvdRza7ta8u_ApyL_eqU43nyUdp0gS6A8/edit?usp=sharing)

I've just had to submit a case to ask for details of 10 'records with exceptions' for the exact type of job for the original submission from 2016 of Filter set.
I feel like Ex Libris requesting a list of prioritised jobs is quite simply just a stalling technique.
Even if not, there are several jobs listed here already for years now. What is stopping these from being considered that exact prioritised list as requested and just get it done?
It's ridiculous that there is not simply a link we can click on to download a file of these records, and we must instead put in a case.
We all know how bad response times are for cases and my experience is that they are only getting worse. So we have to wait weeks and sometimes even months just for a simple report and in the meantime our work is stalled.
Surely it is a better use of time as a vendor company for Development to do a one-time effort to improve the product so that customers can self-help, rather than pushing the burden of work to Support in a constant stream of requests.

We are close to 500 votes. Will we have to wait for the 10-year anniversary of this suggestion to get an answer ?

Perhaps at the next User Group meetings, reps could ask ExL to comment on this Idea? it now stands at 441 Votes!

We're coming very close to the 6.5 year anniversary of this idea. Is there any forward movement on this?

I agree that it is always painful when Discovery Import Profiles (Import Data to Primo VE) complete with errors because some harvested records failed to load. We must always open a case and provide the process ID, so that Support can tell us which records could not be imported. Of course, we rarely get an answer in the next fex days at Tier 1... If we could directly see in the job Report which records have failed, we could quickly fix the issue ourselves, either in correctling the source data (if they are ours) or by updating our normalization rules accordingly.

I support this idea. I noticed an error in the exceptions column: in the synchronize user reports, there are 0 exceptions even when there is a rejected user in the report, and this enforce me to open each report.
Naomi

I would like to make the bold suggestion that it should work for all jobs.
Prioritize all jobs that can be run manually.

Thank you for posting this idea, and for the informative comments! We've noticed several different jobs mentioned in the comments - could we please ask you for a prioritized list of job reports that you would like improved?

From University of Barcelona are very interested in this idea. We would like to add the need to receive by email the number of Identifiers of the failed records (bibliographics, users, etc.)
Will be great if we can get the list of failed identifiers for each synchonize users job, either to receive it by email, or else to put the report file (plain text, please) at the same sftp server used to upload the user files.

Another extremely necessary but languishing idea that has a large number of votes. Please consider implementation soon, Ex Libris!

This is the top voted submission for the Alma Idea Exchange at 329 votes.
Ex Libris states this as the preamble statement for this forum: "We would love to be able to respond to every idea that is submitted, but this is not feasible. We are, however, committed to responding to the most popular ideas—those that have received the most points."
Despite this stated commitment, there is no response from Ex Libris in the 5 1/2 years since the submission was added.
If there are no plans to deliver this functionality, then the idea should be Closed so everyone knows that Ex Libris will not fulfill it, and gets their votes back, and perhaps consider aiming for certain roadmap commitment via the NERS process.

For troubleshooting failed discovery import profile jobs. We need to know which harvested records cause the errors, not simply what the error was.

I would add that the list of reasons of failure has to be updated. For example, with the April release, Alma can now maintain separate bib records for electronic and physical inventory types. However, this is not reflected in the report correctly.

I have given my votes here to combine my suggestion: It would be good to add in this reason "Mismatch inventory type" when two records of the same title but different inventory type are not matched.