Ordering functionality that FOLIO needs to stay competitive (UXPROD-3440)

[UXPROD-2565] Create requests for newly ordered items automatically from the POL Created: 25/Sep/19  Updated: 10/Jun/22

Status: Analysis Complete
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Ordering functionality that FOLIO needs to stay competitive

Type: New Feature Priority: P4
Reporter: Ann-Marie Breaux (Inactive) Assignee: Dennis Bridges
Resolution: Unresolved Votes: 0
Labels: acq-orchid-candidate, acquisitions, needs-ranking, needs-rmsigreview, orders
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Epic Link: Ordering functionality that FOLIO needs to stay competitive
Development Team: Thunderjet
Kiwi Planning Points (DO NOT CHANGE): 4
PO Rank: 89
PO Ranking Note: This can be done manually by navigating to the item record immediately after the order is placed. The ranking reflects that this allows room for error and a less than ideal workflow.
Rank: Chalmers (Impl Aut 2019): R3
Rank: Chicago (MVP Sum 2020): R2
Rank: Cornell (Full Sum 2021): R2
Rank: Duke (Full Sum 2021): R2
Rank: 5Colleges (Full Jul 2021): R2
Rank: 5Colleges (ERM Jun 2020): R2
Rank: GBV (MVP Sum 2020): R3
Rank: Grand Valley (Full Sum 2021): R3
Rank: MO State (MVP June 2020): R2
Rank: TAMU (MVP Jan 2021): R2
Rank: U of AL (MVP Oct 2020): R3

 Description   

Overview:

Allow users to add enough request information to the order to generate a request on the item being ordered when the order is opened. This way patrons can be notified that the item they requested has been ordered and follow it's progress.

Note: proposed by Duke (Julie Brannon, Erin Nettifee)

Use cases:

In scope

  • Allow user creating order to toggle a "Create request" action if the requester field is populate by a User ID.
  • If "Create request" is true than orders app will automatically place a request on the first item record created on behalf of the requester when the Order transitions to Open.
  • In order to create request the system must have a requester user id and Pickup service point in POL
  • If not making a request the system should allow free text in the requester filed.
  • Pickup service point and requester user id is ONLY required if "Create request" equals 'true'.

Questions

  • It seems we may need to add an option for the Fulfillment preference after all?
  • Regarding Hold vs. Recall can an assumption actually be made here or would it need to be a setting?
  • Another use case: alerting a user to a newly-available, ordered eBook, which does not have an item record. Is there a way to create a patron request for that? Should that perhaps be a separate feature?

Links

See proposed mockups: https://drive.google.com/drive/folders/1SpOvkcoQLuI0P0tpf_Le-924gKtTYzPM?usp=sharing



 Comments   
Comment by Ann-Marie Breaux (Inactive) [ 25/Sep/19 ]

Dennis Bridges This came up in a Slack convo with Duke - see details in the description above. Could we consider adding a "create request" button, or automating some functionality based on the requestor field being filled in on the POL? I think the safer path would be a button, since the requestor field may or may not actually want to have a hold for the ordered book. Plus anything we can do to minimize having User info in the order record (especially user barcode number or other ID) in the POL will be more acceptable to the Europeans.

Added Erin Nettifee and Julie Brannon as watchers

Comment by Erin Nettifee [ 25/Sep/19 ]

Cate Boerema and Andrea Loigman - FYI - this is an Orders feature request that will intersect with Requests.

Comment by Dennis Bridges [ 25/Sep/19 ]

Ann-Marie Breaux cc Erin Nettifee would it make sense for the request to result in an order being created? If not, is the user creating an order and creating a request at the same time or are they creating the order and linking it to an existing request? Happy to discuss this and get started on a wireframe.

Comment by Erin Nettifee [ 25/Sep/19 ]

Hi Dennis Bridges

Basic process is like this.

  • Patron A requests that Librarian B buy a book, and that the library hold it for them when it arrives
  • Librarian B creates the order, and notes that Patron A asked for it and wants it held.
  • Somewhere in the order process, Patron A gets a hold placed for the ordered item at the point at which the item is created and holds are allowed to be placed. That's the important part because if on order items allow requests to be placed, you want Patron A to be first in line.
  • When the book arrives and is processed and sent to its location, the check in of the item starts the process of filling the hold for Patron A.

So it depends on when creating an order results in the creation of an item, which I don't know enough about to tell you.

Does that help?

Comment by Dennis Bridges [ 25/Sep/19 ]

Erin Nettifee Yes, it does thanks for the additional detail. We currently have a requester field (as noted above) in the order record that is simply a text field. My thinking is that this could be a "Requester lookup" (as mentioned in description). Thus allowing Librarian B to pull the necessary requester information for Patron A. From that point the system knows the requester and the title. Thus, when mod-orders creates the item(s) in theory we could also place a request for the requester on the first item. However, this would be complicated if the order is for "New York Times", for example, and the request is for issue 4. In this case something would need to be done during receiving in order to identify the specific "Item" that the requester was looking for. Would you say this is a common occurrence?

Comment by Ann-Marie Breaux (Inactive) [ 26/Sep/19 ]

Dennis Bridges We may need to have a less-controlled and more-controlled way of dealing with the requestor. For some libraries, it's just informational - which department or faculty member wants the thing, but it doesn't always necessarily lead to creating a hold.

In any event, the sequence that I'm hearing is
1. Get a request from someone to purchase something
2. Create the order, and the order creates "on order" items in FOLIO
3. Once the item record exists, have FOLIO automatically create the FOLIO request (usually a hold) for the user who requested the thing
4. When receiving/check-in, if multiple copies or volumes, have an alert that one of the pieces has an open request on it, so that one can be received first [a Chalmers priority documented in a separate Jira]
5. Once received, have a reminder to route that piece differently from non-requested pieces, so that FOLIO request can be fulfilled [a Chalmers priority documented in a separate Jira]

Thanks,
A-M

Comment by Julie Brannon [ 26/Sep/19 ]

Ann-Marie Breaux The sequence you've outlined above sounds accurate, though we'd like to see the requestor ID changed to a dynamic user lookup rather than text (as it was probably planned from the beginning and mentioned by Dennis above). European users could choose to leave that field blank, as needed.

To Dennis Bridges's question above, I'll need to dig around to find out whether requests might be at the volume level within a serial or set; though the alert described by Ann-Marie could address that scenario when needed. Thanks!

Comment by Ann-Marie Breaux (Inactive) [ 30/Jun/20 ]

Hi Dennis Bridges Added a couple comments at the bottom of the description based on a mtg just now with 5 Colleges.

Anya is asking how this could get ranked. It's not linked to a particular UXPROD feature. Do we have one for automating some of the interactions between requestors and orders? Or maybe we could create one and link this to it?

Comment by Dennis Bridges [ 30/Jun/20 ]

Ann-Marie Breaux Yes no problem, I think given the detail here and the interest from other parties it should probably be written as a feature and prioritized accordingly. I can pick it up from here, convert it and discuss it with the RM group?

Comment by Dennis Bridges [ 06/Jul/20 ]

Moving this discussion from the description to the comments:
??From Julie and Erin: We are trying to understand how to process patron requests for an order in FOLIO. I'm trying to find whether there is a JIRA to watch for functionality to place a hold on an item that has been ordered at the request of a specific patron and I can't find one. This was raised this as a missing feature during the April gap analysis, but I'm not sure whether a JIRA has been created. I see on the PO Line that we can add the "requestor" in a text field and click the "Rush" flag. Is there a JIRA for a future feature that would take action based on those values?

For example, at Duke when a patron requests that we order a title, we would flag it as a rush order and capture the patron ID on the order record. Upon arrival a hold is put on the item so that it can't be loaned to anyone else. In this morning's demo you set up a patron request - there was no automation to create the request automatically. Just looking for any JIRAs related to features that might come in future releases.

Ann-Marie Breaux:
Hi Julie and Erin,
If FOLIO is creating the item record at point of order, then you can add the Hold immediately, instead of storing the user barcode/name in the order record. Once the Instance/Holding/Item is created, go to the "on order" item record and create the Hold from there.
Let me know if you want to take a look at it together. Thank you!

Erin Nettifee:
Right - the feature request is to have that hold created automatically
to put the requester name into the order as part of the order process, and have it create the hold.

Ann-Marie Breaux:
I think the Europeans will have some privacy issues with that scenario. Maybe another option would be to have a "create hold" button in the POL that opens the new requests screen automatically, so that you can enter the data there, instead of having to put the user name or ID into the order record.

Julie Brannon:
Thank you for helping us puzzle through this one. That’s an interesting thought – I can’t get too excited since it takes us a step back from our current workflow at Duke. Our order specialists don't create hold requests currently and will likely gripe about losing functionality which currently automates that process.

I definitely agree that the hold action needs to happen immediately at the time of order creation to preserve the "first dibs" priority of the original requestor so that they don't get bumped if a request sneaks in as soon as the item is created. Putting a "create hold" button is friendlier than asking them to toggle over to the item to create the hold.

It seems like they would need a slightly modified request builder pop-up window because they wouldn't have the item identifier at the point of PO line creation - the item isn't created in inventory until the order is opened, right? So if all they have to do is remember to click “create hold” and enter the patron information that wouldn’t be much different than what they do now. Just thinking out loud.

This is a high volume process at Duke and will cause grumbles if we don't have a smooth process in place. What is the next step for addressing this - would this be a new JIRA or is there one floating out there already?

June 2020: Adding a comment that this is of interest to 5 Colleges too. Also being able to send automatic e-mails for notifies (not holds) when material is received.??

Comment by Ann-Marie Breaux (Inactive) [ 25/Sep/20 ]

Hi Dennis Bridges Just adding a comment that if the requester field becomes one that has a user ID/number in it, we still may need an uncontrolled text field for requester, in situations where a library wants to record a requester, but not their ID. If the same field can be used for both, that's great. Otherwise, maybe we create a new field for Requester ID and leave the existing Requester field uncontrolled.

Comment by Erin Nettifee [ 25/Sep/20 ]

Want to point out a few things:

For requests, there are five required fields (at least as far as I've understood it) - itemId, requesterId, requestType, requestDate, and fulfillment preference. Some places may want to do holds but I could also see some libraries wanting them to be recalls (to trigger faster action by staff, maybe) so that may not be able to be hard-coded. Then fulfillment preference is meant to be "hold shelf" or "delivery" and likely will actually need to be pulled from the user record, rather than set by staff. If you haven't talked to Cate already about this, that would be my recommendation. There's some active work happening around improving item delivery workflows on the RA side that could impact the description of this feature as well.

Comment by Dennis Bridges [ 25/Sep/20 ]

Erin Nettifee Is the request date something you see the user wanting to set through this process? If so, is it safe to allow them to give us a date? Otherwise we would be using the date the order was opened.

Comment by Erin Nettifee [ 25/Sep/20 ]

No - it's mainly used for ordering in the app itself, and for decisions to expire requests that haven't been filled. Using the date the order is opened would be the date the request is created, so that makes sense to me.

Comment by Dennis Bridges [ 28/Sep/20 ]

Additional comments form Cate:

  • Request expiration date is optional, so it's really up to the user whether you want to make it settable in the order. FYI, we do have an open feature in the backlog for collecting a tenant default for this field: https://folio-org.atlassian.net/browse/UXPROD-1628
  • Re: Type:
    • I don't think users need to make a selection here. If this is guaranteed to be the first request on the item, it should be a Hold (not a Recall) and you could just select that option automatically.
    • What is the workflow for fulfilling the requests for On order items? Are they scanned into Check in app when they are received? What service point is used for the check in? Is there a receiving service point?
  • Allowing the selection of a pickup service point assumes that the requester wants Fulfillment preference to be Hold shelf. That's not always the case. Some patrons are allowed delivery and prefer items to be delivered. To support that, you might want to allow the selection of the fulfillment preference and, if Hold is selected, the pickup SP. If Delivery is selected, the Delivery address. If defaults are specified in the user record, they should be used.

Dennis:

It seems we may need to add an option for the Fulfillment preference after all?
Regarding Hold vs. Recall can an assumption actually be made here or would it need to be a setting?

Comment by Erin Nettifee [ 18/Mar/21 ]

Brooks Travis this feature came up in conversation at Duke today - not sure if you've seen it or not.

Comment by Ann-Marie Breaux (Inactive) [ 18/Mar/21 ]

Erin Nettifee and Brooks Travis One significant architectural issue for this feature (at least in my mind) - currently the requestor field in the POL is uncontrolled. In earlier conversations, Duke talked about changing the requestor into a controlled field with FOLIO User info. If that ends up being a requirement, I think we should consider added a separate field for a controlled version of the requestor, rather than changing the existing uncontrolled field and forcing that requirement on all the FOLIO libraries

Comment by Ann-Marie Breaux (Inactive) [ 30/Mar/21 ]

Another use case that came up in Acq Group mtg today: alerting users to a newly-available, ordered eBook. If there's no item record, how could a request be handled? Added as an open question in the description. Might need to be split to a separate feature.

Comment by Erin Nettifee [ 30/Mar/21 ]

Requests is not architected for using non-item records, so it would likely need to be some sort of notice feature to the patron rather than using the Requests app and associated features.

Comment by Ann-Marie Breaux (Inactive) [ 30/Mar/21 ]

Thanks Erin Nettifee To me, in that case, that definitely sounds like a separate feature .

Generated at Fri Feb 09 00:25:01 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.