:email::electric_plug: Email integration, UX iteration 2

Working with another RM related feature, this idea of a potential first iteration of email integration came to mind. It sprang from a comment from one of the subject matter experts, saying that getting some of the library communication out of the email client might help boost productivity.

The notion of adding Notes by email, would allow end users to forward emails from vendors, patrons and more rather than having to manually copy paste it to FOLIO, and rather than having to keep all dialogue in the email client. The email format would then allow FOLIO to potentially save the formatting of the email to display inside FOLIO as HTML.

(This concept relates to some of the original RM concept discussions, which can be found here and here)

@kmarti, perhaps this could be discussed in a 10 minute section in one of the RM SIG meetings?

This is a most useful feature in the area of ILL as well. Some ILL requests can contain quite long discussions with several parties until the loan is issued.

I cannot remember if we implemented this in the ILL system we developed at Stockholm University Library, but it was a feature pretty high up on the backlog.

But I think that the tasks I am thinking of solving with this also would need the Notes app to be able to SEND emails to various people. But I think that it is just logical to have that as well since you otherwise would miss half of the email conversation

Thanks for your comment, Theodor @ttolstoy!

In the longer run, having an integrated dialogue option to integrate email and Notes would be meaningful. I wonder if having just the ability to forward emails to FOLIO records that then get attached as Notes, might be a meaningful first iteration?

If you have any more details about the use cases you know about, please feel free to share them here so we can keep them in mind going forward

Yes! I think this would be a big workflow support. Just let me know when.

Here is just an example @filipjakobsen:

• A request for an ILL/Purchase (the patron should not have to know the difference) is entering the system.
• The request is lacking some vital data, like there is no year or edition information.
• The Librarian reaches out to the patron asking for this information
• The patron responds
• The librarian sees no need for purchasing the book and reaches out on the national ILL system to request an ILL.
• The library with the only Item in the country responds that this Item is only to be read under supervision on premise in the borrowing library.
• The library reaches out to the patron to ask if he/she wants to go ahead and read the item under these conditions or if they should do an international ILL instead for a fee.
• The patron responds that he/she wants to do an international ILL
• The library reaches out to some International ILL service via email making the request.
• The book arrives…

There is so much emailing going on here that I think could be handled much better inside of the system. Of course, some of these tasks could also be automated, but I think you get the picture.

Thanks for the examples, @ttolstoy!

I could go on for days when it comes to ILL…

E-resource acquisitions workflows, and troubleshooting workflows, often involve back-and-forth discussion between staff and patrons similar to what @ttolstoy has described. Examples:

• A subject librarian requests that Tech Services staff order an e-resource.
• Tech Services staff reach out to the vendor to ask about price quotes and license terms.
• The vendor responds with a price quote and an attached file for the license to be signed.
• The licensing librarian write back to the vendor to request changes to the proposed license.
• Much back-and-forth negotiation over license wording.
• Final license gets signed by both parties.
• Vendor sends invoice, or Tech Services request it.
• Emailed activation notice is sent to Tech Services to notify us that the e-resource is now available to our patrons.
• Except it isn’t actually available, or something is buggy, so Tech Services writes back to the vendor to ask why.
• Much back-and-forth about how to fix it, possibly including screenshots, spreadsheets of IP ranges, etc. attached to the emails. Possible passing around of the problem from one library staff member to another.
• Fixed! Yay! Issue closed!
• A year passes. Then a patron reports that the e-resource is broken again, in exactly the same way as it was broken the first time.
• More back-and-forth!
• Every dang year!

Also - since there might be patron identifying information in the emails, it would be useful to have some quick and easy way to redact that particular information if need be. An “Edit” button that includes an option to select text and replace it with “PATRON” or something?