Allow Local Create List Saved Exports
Create List supports "Apply Saved Export." However, it has a 100 max limit. In large institutions or consortiums users hit this limit. This requires users to manually configure what can be complex export data by hand every time.
Sierra's Create List supports loading locally saved queries via JSON. Global update allows the user to Load (Local) commands. Extend Sierra's Create List to Load (Local) saved export fields. This increases efficiency and eliminates errors.
Idea Value
In our institution, there are no available Saved Export slots. As a result we often have to configure complex export data by hand. This introduces errors: the user forgets to export a particular field.the user accidentally keys in the wrong field.the user exports the fields in the wrong order.they choose the wrong delimiter...
All of these are especially true if the list of fields is numerous enough that the scroll bar is engaged. Any of these will require the user to go back in, tweak and re-export the data, which may take time when exporting large lists.
One alternative is to use SQL and query the backend. However, not all users have access to this functionality or the training to do so. Being able to load a Local Saved Export eliminates those issues and speeds the process.
Another option is to increase the Saved Exports max. However, if you allow it, they will fill it. That provides even less incentive for staff to review/clear older export files and increases the likelihood of "orphaned" exports. (See scenario 4 below)
The Local Saved Export should support the same fields as the Save Export function.
Some possible scenarios:
Scenario 1. It's report time! To provide fy reports, a user queries a year's worth of data and returns 11 data fields for each record. Due to tight deadlines, this data is exported and pulled into Excel where macros slice and dice the data. Those macros are dependent on the correct data being in the correct order. Any mix up requires re-exporting the data or updating the macros. Either takes time and adds stress to a situation where the user is already in a time crunch.
Scenario 2: A sierra user has limited familiarity with Create List, but needs to run periodic reports. The local Sierra expert has created a local JSON query that the user can just load in Sierra and Excel macros to ingest and compile the data. Unfortunately the user misses a field or puts it out of order and then has to figure out what went wrong or wait until the expert can help them debug.
Scenario 3: The library is short staffed. As a result staff are performing tasks that they are unfamiliar with. To streamline processes, the library has saved queries as JSON which anyone on their team can access. However, exports are still a manual component where errors may occur. The entire process is more efficient and accurate, if both the query and the required export fields can be loaded from a local file.
Scenario 4 (NEW) - identifying who owns the various Saved Exports. We asked folks to review/purge unneeded Saved Exports. However due to staff/project changes we ended up with "orphans" where we could not identify all of the owners/projects. (Some saved export names|data did not necessarily identify the owner in our large library. ) We are storing create list JSONS in our networked file directories with their projects. That allows us to identify the department/project/possible owner. Being able to place the Saved Exports in the same directories co-locates all the data together and makes it easier to manage. No more orphaned searches or export profiles on Sierra.
-
AdminJulie Cole (Admin, Innovative) commented
MEEP candidate March 2024