Alma and Item Process Types

Two different things with confusing names

Ex Libris uses different language to refer to process statuses on items on Alma. There isn’t really a central explanation that I can find of what they are - it’s kind of sprinkled all through. This page is a good place to start at least:

https://knowledge.exlibrisgroup.com/Alma/Knowledge_Articles/Why_does_the_item_editor_show_two_different_values_for_Process_Type%3F

Automated process types

Items can have automated process types (Ex Libris will also sometimes refer to them as system process types.) These represent different workflows and the values are applied as items move in and out of those workflows.

These values show up in Physical Items search as “Process Type” - see screenshot.

Open

A table of automated process type values is below.

Work order process types

There are also work order types, which sometimes are referred to as process types in documentation. They also sometimes are referred to as manual process types.

These values show up in physical item search as “In Process Type” - see screenshot below.

Open

Items that are in Work Orders

Items that are in a work order will have an automated process type of WORK_ORDER_DEPARTMENT (“In Process”) and a manual process type that is the name of the work order type.

For example, if an item is being searched for by Perkins Access Services, it would have an automated process type of “In Process” and a manual process type of “Missing Items Search.”

Here is an example screenshot from Physical Items Search:

Open

And an example screenshot from the item edit screen:

Open

Controls for Requesting

Current default approach - disabling requesting

The current default rule disables requesting for items with a process type of ‘In Process’. We would have to write rules to exempt the use cases where we want requesting to occur.

Positives:

• Disabling requesting automatically allows us to cleanly direct eligible patrons to interlibrary request to get items - which in many cases is faster than pulling an item out of local workflows.

• It prevents patrons inadvertently thinking they can access something that is not accessible.

• This is how Aleph functions - requesting is disabled unless explicitly allowed.

Negatives:

• We can inadvertently set up scenarios where patrons are not able to access materials that are needed.

Other considerations

• Enabling requesting on items in work orders means that those patron requests need to be monitored. If an item in, say, a preservation workflow is requested, the request will show on the item’s record in the “manage in process items” user interface, but no emails will be triggered and no slips would print for items to be pulled. We would need to have clear lines of understanding for each workflow that allows requesting to ensure that if a patron needs an item, the request is noticed and processed in a relatively timely manner. That can be processing overhead. If that’s not feasible, then the option to disable requesting by default would be more desirable for patrons because it would send eligible patrons to interlibrary loan.

Easiest controls - Fulfillment Settings

We have only two individual settings for automated process statuses - everything else is controlled through fulfillment units and their rules.

• missing_item_requestable - we can choose whether missing items are requestable. We have this set to false.

• close_paid_lost_loan - we can choose whether to mark lost items that have been paid for as Lost and paid. We have this set to false because of ramifications with the bursar fee export. That means that post-cutover, you should not see items with this status in Alma.

Everything else - Fulfillment rules

For all other automated process statuses, we can use fulfillment rules to control whether or not an item in a particular automated item process status can be requestable or not.

We must be able to write a rule to match on the item that we want to control. Rules match on one or more parameters with an ‘AND’ match if more than one parameter is included.

The following parameters can be used in rules:

• Location - shelving location of an item

• Patron user group - user group of the patron who wants the item

• User statistical category - statistical category on the user record of the patron who wants the item

• Job category - job category on the user record of the patron who wants the item

• Item policy - on the item record

• Material type - on the item record

• Patron affiliated campus - we don’t use this function on patron records

• Process type - on the item record

The process type parameter is specifically referring to the automated process type, not the work order type.

Current Behavior and Use Cases - thinking through requesting behavior

Use case 1: New and Noteworthy

When an item is received at Perkins for the New & Noteworthy collection, there are generally a few manual tasks that must be done for the item (spine flags, colibri covers, etc.) While that work is happening, the item can come out of the Acquisition status, but we do not want them to show as Available / on the shelf. Therefore, we have a work order type called “Access Services Processing” where these items can be held during the few days they are being physically processed prior to shelving.

We want patrons to be able to continue to request items in New & Noteworthy during the processing time.

Use case 2: Items being searched for (“Missing items search”)

If an item is missing and being searched for, we want to track the item so that we know how many times it has been searched for before declaring it lost. We place the item into the work order called “Missing Items Search.”

Items that have been marked missing should not be requestable. (Note that the parameter missing_item_requestable being set to “false” would also be a way to address thiis use case.)

Use case 3: Items being sent to binding

Items being sent to binding must have a work order applied to them so that the record properly reflects that they are not on the shelf.

Items being sent to binding should be requestable.

Use case 4: Items that are damaged

Items that are damaged must be sent to Preservation for evaluation and potential repair. They must have a work order applied so that the record properly reflects that they are not on the shelf.

Items sent for evaluation of damage are currently requestable in Aleph (which seems surprising.)