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.

As mentioned by others, can Ex Libris please merge these two submissions into one, so that we can see a true picture of the desire for this functionality and don't split our votes?
Right now there are 85 votes on one and 78 on another, putting this underlying idea at 163 votes. From a quick skim of the Top ideas, this would put it in the Top 30.
https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/34532095-access-detailed-error-reports-for-all-jobs
https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/15192714-improve-alma-job-reports-for-failed-record

As mentioned by others, can Ex Libris please merge these two submissions into one, so that we can see a true picture of the desire for this functionality and don't split our votes?
Right now there are 85 votes on one and 78 on another, putting this underlying idea at 163 votes. From a quick skim of the Top ideas, this would put it in the Top 30.
https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/34532095-access-detailed-error-reports-for-all-jobs
https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/15192714-improve-alma-job-reports-for-failed-record

This is also an issue for us - We run regular 'publish to OCLC' jobs from Alma.

Each job history returns a report of:

- new records added
- existing records deleted
- updated records
- Not published records (record content did not change)

But this report does not identify WHICH records have been actioned, and this severely curtails our troubleshooting efforts.

This would be very welcome, it would indeed save time to both customers and Ex Libris in a lot of situations. It is very frustrating sometimes to be working on something and have to stop due to the need to open an incident with Ex Libris when in effect, the log reports often contain information meaningful enough to help solve an issue there and then (my recent example: there were duplicate accounts for the same user resulting from our recent data migration, which prevented job report emails to get through and the exported file to be saved to the local folder since Alma didn't know which user account to use; it was a simple enough solution once this information was known that could have been dealt with straight away).

I don't have any votes left I'm afraid but the ability to identify failed records is absolutely essential now that so many of us are exporting records to other discovery layers to expose collections. e.g. in the UK many libraries are exporting records to the National Bibliographical Knowledgebase. Setting up the feed to this service was simple (this is one of the best features of Alma!) but now I need to know wich records have failed (not simply that they have) so that I can check for metadata errors and rectify them ready for the next export.
Thanks,

Jane Daniels

see also https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/15192714-improve-alma-job-reports-for-failed-record

see also https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/34532095-access-detailed-error-reports-for-all-jobs

I don't have any votes left but wholeheartedly support this!

Jane Daniels

This would indeed safe time and make things clearer for customers. Thanks for submitting this idea.

University of South Australia Library would be interested in accessing various error reports for the jobs that we run at the time when we run the jobs.
We are aware we can check Import errors as per "Resolving Import Issues" but for other type of jobs we cannot check error reports.
As an example, running a filtering job on a set provides us with a report including a brief information on the number of records that "failed" as in this message:
"Of the 67201 records processed, 4 records failed. For more information view the report details (or contact Support using the process ID)." I attached a file with full details of this report.
We would very much appreciate having access the all error reports for the jobs that we run at the time when we run them, without having to create an incident case asking Support for error reports each time when we have problem records.
We believe that allowing us to check the problem records before creating an incident report would save time for everyone, as we could fix certain problems without creating incidents.
Thank you for your consideration,
Daniela Nastasie

I'd give this all 20 of my votes if it let me. I just had a failed Authorities-Preferred Term Correction job over the weekend. Error says "Of the 223 records processed, 100 records failed" I downloaded the report. I got MMS, Vocabulary code, Field number, Old value, and New value -- no indication of whether these are the changes made or the the ones that failed. I figured, I should be able to tell, since there will be either 100 lines (fails) or 123 lines (sucesses). Nope -- 138 lines. So now what do I do?????