Add option to configure Process Types for Physical Items
Alma Process Types and the associated Base status of 'Item not in place' are hardcoded, as are the automated workflows within Alma and the flow-through to Primo for the availability to be set to 'Not Available'.
This is extremely limiting and there are scenarios when a Library might want their physical resources to still be discoverable in Primo ie not suppressed, but also be marked as Unavailable, such as if there were a temporary mould outbreak. This ensures that users are aware that we hold resources already, so they don't waste time submitting purchase requests or thinking that we have a poor collection, while also avoiding confusion with resources set to 'Available', when the Library does not want them to be.
Ideally, there would be a configuration option available whereby a site could configure a new Process Type, as a static status with no associated automated workflows, add their own label for the Get It display, and be able to run the Change Physical Items job against sets to set this Process Type to add it and also remove it (as can be done now with the Missing process type).
This would then flow through immediately to Primo to mark these resources to be 'Unavailable' by the availability status, and display the associated label in the Get It by RTA (Real Time Availability).
These configurable Process Types would also be added to Analytics, along with the existing hardcoded Process Types, in the Physical Items subject area, for tracking and ease of handling.
It's so wonderful to see the community support for this idea, both here and in the annual 2021 Alma enhancements cycle, to get my #7177 submission to No.1 position in the final round voting.
This will be a significant positive level of development to our autonomy of record management in Alma, and through into how we choose to make our resources discoverable in Primo.
Thank you everyone for supporting this enhancement with your valuable votes.
I have submitted this idea to the Alma 2021 enhancement round, so everyone who has voted here who is interested, please consider sparing some votes for it as #7177 "Add option to configure Process Types for Unavailable Physical Items, without creation of requests".
The important sentence in this Idea:
"(to) be able to run the Change Physical Items job against sets to set this Process Type to add it and also remove it"
Currently it is possible to run a bulk job to "Create physical item work orders" - so this is not the problem - but there is no job to delete them with a bulk job. Since we started with Alma, we have discussed the issue with Ex Libris employees (in support meetings and salesforce cases). Unfortunately unsuccessful :-(
Of course, there is a risk that there may be user requests for some items. But this can also be found out with a simple analysis of the items before the update and these items can be treated slightly differently (i.e. not with the bulk job).
See also: Bulk Work Order Functions
Jennifer Browning commented
This would be extremely useful for the context that Stacey has specified here for reasons related to COVID-19 responses. We would like to have our Reserves collection discoverable in Primo but show as Unavailable or Temporarily Unavailable.
For organizational purposes and so that it will be easy to fiind this presentation I am putting a link to it in a public comment:
How to add an additional process type to Alma using the Work Order functionality.pptx
We will investigate the latest comments regarding the desire to be able to update the process type in the change physcial items jobs without creating a work order.
Another use case: We have put this into place again for one of our Libraries, as part of our COVID-19 response, to ensure our collections remain visible, while still correctly marked as Unavailable by brief results availability and 'Temporarily unavailable' by Get It status.
Alma should be flexible enough to allow library staff autonomy to display our records in this manner when we need it, in a quick and easy process, so that we don't have to co-opt another hardcoded process as a workaround.
Manu Schwendener commented