Many institutions have needs and requirements to be able to track when Alma configurations change, and who changed them.

This is especially true because many Alma "administrator" roles combine complex librarian tasks with systems configuration abilities. For example, Catalog Administrator or General Systems Administrator is required to create new metadata import profiles - a task that catalogers need to do regularly. But, both roles also grant additional abilities to configure Alma behavior for resource management,
integrations and the like.

Use cases include:

• Monitoring changes as part of standard internal audit review. For example, an institution may identify that even though electronic resources staff need Fulfillment Administrator in order to manage general electronic services, none of those electronic resources staff should be changing other areas of fulfillment configuration. Because Alma's roles do not separate those duties, the secondary requirement would then become to monitor changes in the fulfillment configuration areas outside Discovery Interface Display Logic to know which staff members are changing them and when. We would want a regular report that logged information like the name of the logged in user, the name of the table, the date/time the change occurred, what row(s) changed, and what the prior and new values were in those rows.

• Troubleshooting unexpected Alma behavior. For example, suppose that custom linking for a set of CDI databases begins to behave unexpectedly. Configuration for those database links is handled in Configuration > Discovery. A staff member hears about the database issue, goes in and attempts to fix it,
  but can't. The issue then gets reported to a systems staff member. At that point, the systems staff member can only see the last updated by and timestamp. They need to be able to see who edited that table, and when, to help figure out what
  might have happened.

Analytics currently has a subject area called "System Events" that does a poor job of capturing this information. For example, there is a system event type 6141 - Mapping table updated. However, the information captured there is internal tracking information and not actually relevant to mapping table updates, according to Ex Libris support.

Improving how this data is kept and tracked would go a long way towards reducing risk of Alma not functioning as expected, and making it easier for institutions to manage audit requirements and troubleshooting needs for Alma users.