CSU Libraries’ Alma & Primo Analytics Consortial Folder Policy (Draft)

Introduction

A.  Purpose of the Policy

1. The purpose of this policy is to establish clear guidelines and standards for the management and organization of analytics objects stored within the CSU libraries’ consortial folders in Alma & Primo Analytics while preventing the accumulation of outdated or unnecessary reports. This policy outlines the required naming conventions and provides examples of report descriptions.

B. Scope of Policy

1. This policy applies to all employees and stakeholders, within the CSU libraries, involved in the creation, storage, and utilization of analytics objects in the CSU consortial folders in Alma & Primo Analytics.
2. CSU consortial folders include the Network Zone folders, the CalState community folders and their subfolders
1. Network Zone folder path in Alma Analytics: /Shared Folders/California State University Network
2. CalState community folder path in Alma Analytics: /Shared Folders/Community/Reports/Institutions/CalState
3. Network Zone folder path in Primo Analytics: /Shared Folders/Primo California State University Network
4. CalState community folder path in Primo Analytics: /Shared Folders/Primo Community/Reports/California State University
3. The policy does not encompass analytics objects stored in personal/non-consortial analytics folders i.e. “My Folders” of the Network Zone or the Alma Analytics in the Institution Zone.

C. Responsibilities of Users

1. All users involved in the creation, storage, and utilization of analytics objects in the CSU consortial folders are responsible for the following:
1. Following the specified naming conventions for analytics reports and including thorough report and folder descriptions, as outlined in the policy.
2. Storing shared reports in appropriate folders.
3. Refraining from storing reports created for individual use in CSU consortial analytics folders.

Consortial folders: What is stored where?

A. CalState Community Folders

1. Analytics objects that need to be shared with institutions outside of CSU can be placed in these folders.
2. The CalState community folders previously held reports shared within CSUs. For example, the ACRL IPEDS Official ULMS folder has been moved to the Network Zone folder. Do not use the copy under the Alma CalState community folder.
3. The subfolder hierarchy for the CalState community folders is still to be determined. Many of the subfolders in the CalState community folders will need to be moved to the Network Zone folders.

B. Network Zone Folders

1. Analytics objects that need to be shared with other CSUs, are for CSU-wide committees/groups or need to be run on the NZ data can be placed in these folders.
2. The Network Zone folders contain the same default subfolders as your institution’s folder in IZ analytics. These include Dashboards, Data Visualization, Prompts, Reports and Subject Area Content subfolders. The analytics objects are divided by object type into these subfolders. No other subfolders should be created at this level.

(Screenshot)

3. The Reports folder contains subfolders as outlined below. If applicable, the other folders should adopt a similar subfolder structure.

C. Reports folder in the Network Zone folders

1. There should be no analytics objects directly in the Reports folder.
2. Place reports that are only for your institution in the subfolders named after the institution under the Reports folder.

(Screenshot)

3. Place reports that are for CSU-wide committees/groups in the subfolders named after the committees/groups.

(Screenshot)

4. Place reports created for Salesforce tickets in the Test reports for Salesforce folder.

(Screenshot)

5. Do not create subfolders named after subject areas or functions within Alma. The subfolder names should name the owners or the purpose of the reports.

a. Good subfolder names:

(Screenshot)

b. Bad subfolder names:

(Screenshot)

D. Report Naming Format

1. Required:
   1. <what you’re measuring> by <what you have as detail>
2. Optional:
   1. with prompt / without prompt
   2. Run in IZ / Run in the NZ
   3. Institution name or code

E. Example: Proper Report Name

1. Most Requested Loans by Title
2. Usage Measures by Institution

Description Standards for Reports and Folders

A. Importance of Thorough Descriptions

1. Thorough report descriptions provide context for data interpretation enhancing the usability, accessibility, and reliability of analytics reports. Similarly, thorough folder descriptions improve findability and ensure relevant reports are appropriately grouped together.

B. Elements in Folder Descriptions

1. Required:
   1. Purpose of folder
   2. Creator/owner of folder (if applicable)
2. Optional:
   1. Folder review periods/dates
   2. Should contain / should not contain
3. Example:(Screenshot)

C. Elements in Report Descriptions

1. Required: 
   1. Purpose of the report
   2. Technical details (may include dimensions, filters, and/or prompts)
   3. Creator/owner
   4. Last updated by and date
2. Optional:
   1. Prompt for /prompt by
   2. Run in NZ / Run in IZ
3. Example:

(Screenshot)

Maintenance and Clean-Up Procedures

A. Responsibilities for Updating Report and Folder Descriptions

1. Creators and owners of shared reports and folders are responsible for the following: 
1. Update ownership information in the event of any changes or transfers of responsibility.
2. For reports, update description with last update date as needed, noting any significant changes. 

B. Bi-annual Review Process

1. Utilize the CSU Analytics listserv and CSU Analytics Slack channel to inform stakeholders of the upcoming annual review providing them with a copy of the policy, ensuring they have adequate time to make any required updates before the review begins.
2. Identify and flag reports that may require updates or removal.
3. Provide a list of flagged reports to relevant stakeholders, reaching out directly to report owners if identifiable.
4. The Committee will move objects that meet the deletion criteria to the “Review for Deletion” folder.

C. Criteria for Deletion (all must be true)

1. Report owner has either been contacted or cannot be identified.
2. Report has not been queried in the last 24 months.

Conclusion

A. Process for Policy Revisions

1. The ULMS Assessment and Analytics Committee will update and revise as necessary. 
2. Recommendations for revisions can be sent to the ULMS Assessment and Analytics Committee chair by anyone the policy applies to.

B. Contact Information for Questions or Concerns

1. ULMS Assessment and Analytics Committee members. Refer to “Contact Us” section on the Analytics wiki.

Best practice recommendations

Procedures in Alma