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.

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