Meeting Minutes from Systems & Development ULMS Kick-off meeting, 3/22/16, CSU Fresno

Printing - Lauren showed presentation on behalf of Micah Jeffries, who had experimented with printing in Alma.

SpinOMatic: you use an Alma API key to query the record that exists in Alma to pull back call number information. All will receive a developer key from Ex Libris.
- Printing can be in a batch or one label at a time.
- Dot matrix printers are problematic so they switched to laser labels by the sheet on network printers.
- Alma does not have a mechanism for printing labels.
General printing:
- Output needs to be in an email format.
- SJSU setup emails for certain departments, so did Northridge. Then mapped email addresses to departments in Alma.
- Northridge says that a lot of the printing is reports, but some want to print Marc records. Potential of setting up workflows to avoid printing Marc records for sharing with colleagues.
- SJSU used Namtuk for managing printing. SJSU has it running on a desktop; could be on a virtual server. License fee = $89. You can setup multiple accounts and give them rules about where printing should happen.
  - Might have to enable third party application access (ex. with gmail).
  - Some issues with delays with Namtuk that can be as long as 5-10 minutes when the delay interval is set below 1 minute.
- At Northridge: Outlook rules were too complicated to use
- Sac State: Alma provides an export screen for almost everything. You can, for instance, export a Marc record, download it and then you can print manually. They don’t do a lot of this style of printing.
- Discussed circ receipts; at Sac State these are sent via library email; no physical receipts. Everything on fulfillment side is e-mailed based.
- Hold slips: Sac State says that patron initiates hold request and you would have to decide to put a hold on something in the front end. When you scan the item to put it in the hold location, it should send an email to the patron alerting them of the new location.
- Lots of XSLT templates are good enough out of the box. You can only have one email for fulfillment activity. Sac State had multiple circulation points in the library. They customized the template to display all of that information; cannot have separate templates though. Might be possible to get around this by setting up separate libraries, especially if you have areas with different hours. But then you have to manage separate terms of use for each of those ‘libraries.’ End users will see this in Primo. Northridge will be setting up separate libraries and labeling them as locations.

Questions / topics from larger group:

CSU ULMS GitHub: https://github.com/CSU-ULMS - if we’re not a member, we should join/ask Lauren.
How do you edit your III export table to export data? You can put in a ticket. Work with local cataloging people to discuss what fields need to be included in the export. If it’s not exported, it will disappear. Northridge modified the existing export table because III asked for payment to add an additional export table.
What kind of work does systems entail in a cloud SaaS system? (many of these questions were answered by Sac State)
- Hoping to do less things like setting up loan rules because fulfillment staff can do this themselves. Sac State sometimes has to step in for special circumstances. Sac State talked about challenges with hours modifications and exceptions still being managed by Systems staff.
- Systems does not do as much reporting. Each individual department runs their own reports.
- No running of backups.
- Reporting downtimes: Uptime report for Alma was ~99.8% in the last year (according to Sac State) in the North America hub. All outages Sac State experienced were under 30 minutes.

Other challenges/discussion:

PeopleSoft exceptions for new hires (ex. faculty) who haven’t been processed yet. It’s likely that local patron records can be added as exceptions. Sac State has some instances where users haven’t been moved to Active Directory. They create the account for them on the spot with that specific primary identifier so that it overrides the data when it comes from campus. Challenge with patrons who don’t want to share campus identifier when they haven’t completed hiring documents - you can’t reconcile two accounts. You can switch accounts between external and internal, but not merge. Sac State is about to start purging users.
Decisions to transfer Millennium notes fields is now clogging up patron records. Many things are not important even for historical purposes. Cataloging notes are different; those likely need to be kept.
Sac State Systems Dept helps people with analytics reports.
Systems has to resolve patron account issues frequently at Sac State. They chose to have university username be the the campus identifier. Their campus started a policy of recycling usernames. Shibboleth is better than CAS with accounts because there’s more information about the user appended to Shibboleth user records. Fresno is using unique IDs, not usernames.
Systems at Sac State oversees discovery. To be able to test things, you have to send it from Alma to Primo to publish. You have to think about how you’re mapping your Marc data over.
Sac State recommends that Systems staff manage patron roles. All staff are on CAS accounts, only one person in Systems at Sac State has an internal account (uses CAS account to test). IP range blocking can happen so that only library staff can use.
Group talked about certification since most in Systems will need to have at least one person certified. You can see some of the videos now if you search for “alma administrator.”
Some questions arose regarding Fines and Fees integration with Alma. The Fines and Fees Task Force will provide some documentation on integration options (e.g., how Alma is updated from PeopleSoft / CashNet, etc.)