Title: The impact of configuration on Alma workflows Abstract: When initially setting up Alma, many decisions bear reexamining once you ve worked

Transcription

1 Title: The impact of configuration on Alma workflows Abstract: When initially setting up Alma, many decisions bear reexamining once you ve worked with the system. Join us for a review of highlights of configuration decisions that may have an impact on workflows in different functional areas of Alma. We ll review selective configurations from fulfillment rules to invoice payment that are worth considering as you adapt your work to Alma and vice versa.

2

3

4 Merged the 2 entities into 1 because: 1) Before you couldn t search by the collection name in Primo because you couldn t associate a bib record with the electronic package. You could only search by the portfolios in the package. Electronic Collections and Databases will now have a View It tab where user can click on the native URL link to access the collection/db. 2) Difficult to distinguish between packages (which typically have portfolios) and databases. 4

5 Because there are so many workflows in Alma, we re going to focus on the workflows that tend to have the most questions or workflows that are newer in Alma. I ll be mentioning best practices along the way. 5

6 This is not certification training. That is, we won t look at every option, and in fact will only be covering a few key options that have a direct functional impact. Conversely, if you ve completed certification training, you should be familiar with most of these options. Goal is to identify those decision points where we can say, Choose configuration X if you have the following workflow need, but configuration Y if you have another need. Occasionally you might find that our options dictate considering a new workflow based on the availability of the option in Alma. 6

7

8 Fulfillment units are defined as groups of locations with common policies loan and request. Fulfillment policies themselves are grouped into ToU and bound to the collection via these fulfillment units. 8

9 When defining a TOU, we are presented with the list of relevant policies for the type of TOU. In this case, we wanted to create a Terms of Use for Loans, so the policies that display are only related to loans. The drop-down for each policy type is defined as all of the distinct Advanced Policies we ve configured. You can consider Advanced Policy configuration as the means to populate the ToU drop-down more policies means a more cluttered drop-down. 9

10 Fulfillment units include 3 things: (1)a list of rules (in the last tab which is rules), which determines when each Terms of Use comes into play we ll look at this in a moment. (2)the policy for requesting items on the shelf (on the first tab) (3)and lastly, which locations use this set of rules (in the locations tab). 10

11 What we re looking at here is a pretty typical result from loading a spreadsheet. We see one line per distinct group of user types, plus one line for each item policy type override. This ensures that all of our bases are covered, but it s kind of a sledgehammer approach and creates a lot of clutter note the redundant end-of-year policies and the item policy overrides that potentially don t even apply to items shelved at this ToU s locations. 11

12 So the concepts haven t changed since implementation, and it was a nightmare to fight for the existing simplicity, why reopen this wormy can? It s actually because the configuration spreadsheet makes kind of a mess of things: Many fulfillment units At least as many rules as patron types Redundant or unnecessary item policy type overrides Actual policy configuration is much more flexible, which can (ironically) be used to *reduce* complexity and improve overall troubleshooting ability and policy manageability 12

13 13

14 Here s a simpler set of entirely distinct policies. A few notes I ve used a location-level override in a couple of these rules to illustrate how you can actually have fewer fulfillment units if you want to handle it as rule-level overrides. Be cautious with that, however, as you can see that it can lead to pretty rapidly proliferating rules. Another point that s important to note is that the first two rules are assigned to wholly different sets of the collection (noncirc and reserve items to visitors) but reused the Non-circulating terms of use. This makes ongoing management easier, since if I want to change some aspect of my nocirc policy, I can do it in one place and it will apply regardless of the different rules. Just for general readability I ve chosen fairly brief names but adopted a policy of including the key rule parameters in the Description field. That s really what we re going for here ongoing manageability rather than any dramatic changes to policy. 14

15 15

16

17 This isn t actually much of a workflow-altering configuration, and I ll be brief. I simply want to point this out this highly flexible area of configuration. The major reasons that GES deserve another look are: Inclusion of any OpenURL descriptors in the URL, allowing for highly dynamic URLs depending on the title you re looking at Combination of bibliographic metadata and incoming OpenURL descriptors being pushed into the link. That is, you can ingest and promptly pass on any OpenURLs that come into the u-resolver A useful and more flexible alternative to the built-in ILL link configuration. ILL configuration is much easier, but allows virtually no configuration. GES is a popular alternative. Because you can form a GES as an OpenURL pointed at Alma, this could function as a permalink, including for items not in the collection. That is, you would be storing the querying metadata from incoming OpenURLs such as Google Scholar, Primo Central records, and really any other source. (Note that I haven t seen this tried and would be very interested in anyone s results.) 17

18 18

19

20 There are two options for faculty copies. The simple flags are useful for a fail-safe way to manage instructor copies. The workflow approach requires more steps but offers more control (and fits into the standard workflow for physical items on reserve). 20

21 Background When an instructor gives a personal copy for course reserves, Alma has a means of rapidly creating a bib, holdings, and item from the reading list interface. The system does not have any built-in functionality for searching for all instructor reserves, taking them off of reserve in bulk, suppressing them from discovery, or deleting them. It s useful to create these items in such a way that it s easy to discover and manage these items in bulk. Basic configuration Create a new location called Personal copies (or something similarly descriptive) that will serve as the permanent location for all instructor copies. Set this location as being suppressed from externalization, so that everything shelved in this location will not be discoverable in Primo. We will later move these items to reserves where they will be published, but having a wholly separate location allows us to easily search for all brief items 21

22 created to represent instructor copies for reporting or withdrawing. Creating an instructor copy Once you ve created a course and reading list, you can add an instructor copy by selecting Add brief, choosing to create a physical book or article, and filling in descriptive information. Describe the title using the bibliographic form as you would any title, using local policies as appropriate. For the call number, you may put the filing standard you use (typically instructor name or course code). At the moment, this will have no impact as it will be created in the 082 field of the bib but not added to the holding. (This is scheduled to be corrected in the future, but we ll work around it in the meantime with a temporary item move). Do not select the suppress option that will be taken care of by the shelving location. For the shelving location, use the Personal copies location you created above. The item will be suppressed from Primo until you move it to reserves. Use item policies, barcode, and other inventory description as appropriate for local policies. Making it available for discovery When the brief item and inventory have been created, move it temporarily to reserves and add a temporary call number according to your reserves shelving scheme. Among other things, this will allow it to be published to Primo. You can use any of the standard processes for this placing the request from the item or reading list (for a managed move request that requires the item to be scanned in at the destination), or using the scan in interface (to update the data without managing the request). In any case, you will: Place the temporary reserve location that users can find it Enter a temporary call number according to the filing scheme of the reserves location; this will appear in Primo when users find this resource 21

23 Choose a due back date that corresponds with the end of the term or course Finishing a course When the course ends, the due back date will expire the temporary location and call number, and the item will appear on the pick up from shelf list of the circ desk that services the reserve location. (Note that this may create a burden on circulation staff as courses end and hundreds of items suddenly appear on the list.) By moving these items back to the Personal copies location, these items will be suppressed from Primo. Deleting brief items Deleting the brief items is optional. Some libraries are comfortable keeping these items suppressed indefinitely. Because these items are all in the same location, it s relatively easy to create a set of items that safely only contains these brief items without impacting the permanent collection. The course reserve operator can optionally create a set of physical items to be withdrawn and then point technical services to that list. Note: although a physical inventory operator (which many course reserves operators are) can withdraw items, this is not recommended. They typically cannot delete bibliographic records. It is *much* easier to withdraw items if you have a list of barcodes, and potentially very difficult to identify these bibs without the nice shelved at XYZ location to group it together. 21

24 22

25 In the above, we reviewed a workflow that would handle suppression of items by moving them to and from the reserves location the same way items in the collection are moved to and from the reserves area. For a more lightweight means of allowing the system to handle reserves without mediation, you can use two flags: The course_restricted_field flag allows you to specify a MARC field, delimiter sign and subfield that will be flagged for publishing to Primo. When Primo receives a record with the restricted flag, it can be set up to only display that resource on the reserves tab (using search scopes). When the value of this flag is not blank, a new checkbox appears on the brief item input form that allows you to enable course restriction for this item. The item will then only be publicly available during the course. At the end of the course, the item will either be suppressed or deleted according to course_restricted_bib_data_will_be_deleted in the same area of configuration. When set to true, the records will be deleted entirely. When set to false, they will be suppressed. This flag has no impact if there s no value in the course_restricted_field. For more info, see the online help: Configuring Fulfillment Configuring Other Settings 23

26

27 One of the core concepts of Alma is that workflows in each area of the system are built to be automated and adhere to an internal lifecycle. Here you can see a high-level lifecycle of the major stages of ordering and payment. In these stages, when you see review, we re talking about the initial status of newly created data. So a PO line in review is simply an order line that has been created but not pushed forward in its lifecycle. When data are created via loaders (EOD for orders and EDI for invoices), you can optionally use the review stage to stop them for manual review. You can also create rules so that only certain records are stopped for review. The idea is that you ll ultimately want to automate as much as possible by defining the default rule to be false (meaning do not review ), but have certain criteria (such as vendors sending items you already own on an approval plan) that would flag very specific items for review. Orders or invoices that are missing mandatory information will not be allowed to progress on their lifecycle, but all other flags may be overridden with operator review. Approval works a bit differently, in that the behavior of orders and invoices is distinct. For orders, the approval stage happens after packaging so it s an approval of the PO itself, not the individual order lines. Most typically, this stage is not used. This is particularly true 25

28 for EOD, where the actual order has usually been placed and denying it requires working in the vendor system. The approval stage of purchase orders is most often used when mandatory information is missing (such as an ordering address when the purchase type is purchase and the order fails to send). For invoices it s a bit different, and the use of the approval stage depends on staff needs and workflows. A case for an approval stage would be when more than one staff member inputs data for invoices, but actual approval (and potentially payment requests) go through a single staff member. In that case, you would set up review rules to flag EDI invoices based on obvious characteristics, and you would have many staff members creating invoices and pushing them past review. You would, however, set up all invoices for manager approval. If your library does not have this sort of two-tier structure (and you don t want to use the approval task list as a reminder to request payment), you can disable the approval stage entirely by setting a default approval rule of false. All invoices will then skip straight from review to the payment stage. 25

29 Here are the specific characteristics you have available in setting up these various review and approval rules. We ll take a quick look at the options in a live environment. 26

30 27

31 28

32

33 30

34 31

35 32

36 33

37

38 35

39 Because we migrate subscription POLs with a 30 day receiving interval, getting your intervals in shape to be useful will require a bit of work. Fortunately, the claiming task list can serve as a roadmap to cleanup that s required. Once the job is first run, it will essentially contain most of your subscriptions, and you can work your way through it to update receiving intervals. Alternately, update intervals while checking in issues. The approach you take will ultimately depend on staffing (for training reasons) and time (for whether you can set aside time for a cleanup project). Auto-claim via is a source of difficulty for many libraries. The will go to vendors who have an address type of claim disable that type on the contact address to disable the . Because the is a standard Alma notification, you can manage it as you would any notification edit its contents through Customize Letters or disable it entirely from Letter Activity. If you want to disable claims entirely, the simplest way is the flag Acq Configuration Other Settings auto_claim. Set to N to disable s when a claim reminder is generated. The reminder will still be created, but it won t the vendor. 36

40

41 38

42 39

43 40

44 A few words about the new certification program Initial certification was handled as two days of in-person sessions. For the next phase of this program, we ll be replacing that with an Certified Alma Administrator Program. This repeats monthly and is comprises a mix of recorded and live sessions, followed by Q&A and an exam. The exam is online, available for three days, and scored immediately after taking it. To register, visit the Ex Libris Learning Center at learn@exlibrisgroup.com 41