Building and Maintaining the Reporting Hierarchy

🤔 What is a Reporting Hierarchy?

The Reporting Hierarchy is the foundation of ClassRanked. Each institution has one Reporting Hierarchy which defines how academic units are organized within the institution. It mirrors the institution's organizational structure and allows administrators to group, filter, and compare evaluation data across various levels. The structure is customizable to reflect your institution's specific needs.

Why It Matters

A properly configured reporting hierarchy is essential for:

• Accurate Reporting: Enables inter- and intra-unit comparisons (e.g., comparing a department against its division).
• Granular Access Control: Ensures that admins only see the data relevant to their scope.
• Survey Configuration: Supports filtering, survey question display logic, and aggregation based on unit structure.
• Streamlined Data Management: Reduces manual work by logically grouping sections and instructors.

Academic Unit Types: The Blueprint of your Reporting Hierarchy

Before building a reporting hierarchy, you must define your Academic Unit Types. These are the structural levels that outline how reporting will flow at your institution. Examples of Academic Unit Types include College, School, Department, and Program. You can create as many levels as needed and arrange them in the order that reflects your reporting framework. By default, a "Course" Academic Unit Type is created as the terminal Academic Unit Type in your Reporting Hierarchy.

The order you define creates a parent-child structure. For example: If you define your Academic Unit Types in the following order: College > School > Department > Course, then:

• Every Academic Unit created with the School type must be mapped to an Academic Unit of the College type
• Every Department must roll up to a School.

Common Patterns

While there is no enforced standard, many institutions use one of the following patterns:

• College > Department > Course*
• University > College > Department > Program > Course*
• College > Division > Department > Subject Area > Course*
• College > Division > Course*

These are starting points for inspiration but are fully customizable.

*Course is a mandatory default terminal Academic Unit Type. All Course Sections in your system will report up Courses. Courses are uploaded in the Course Catalog file.

Academic Units: The Building Blocks of your Reporting Hierarchy

Once Academic Unit Types are defined, each Academic Unit you create will:

1. Be assigned one of these academic unit types.
2. Require a unique abbreviation so it can be identified without confusion.
3. Report up to an academic unit of the parent type you’ve defined in the Academic Unit Type structure.

In short: Academic Unit Types define the blueprint of your Reporting Hierarchy and Academic Units fill in the content and must follow those rules.

Hierarchy Flexibility

• The hierarchy can be as deep or shallow as your institution needs. It depends entirely on the granularity of role-based access and reporting your school requires.
• Not all schools have an even hierarchy. We recommend trying your best to create a structure that fits the majority of your academic units.
  • You can insert "shell" levels—empty units that serve as pass-throughs to maintain consistency across branches.
  • You can create a course attribute to assign certain course sections to a reporting level not in the Academic Unit.
  • Before choosing, please work with your ClassRanked customer success lead to figure out which pattern works best.
• Not every level needs to have admins assigned. You can choose to leave some levels purely structural.

Building the Hierarchy

Step 1: Gather Structural Information

Collect the names and abbreviations used for each academic unit at every level.

Step 2: Create the Hierarchy File

Use the reporting-hierarchy CSV format specified here. Each row contains 1 academic unit with the following details.

• Title : The title of the academic unit (e.g. Department of Computer Science)
• Abbreviation : The shorthand abbreviation or code used to identify that academic unit (e.g. CS)
• Academic Unit Type : The Academic Unit Type of this academic unit (e.g. Department)
• Parent Academic Unit : The Abbreviation of the parent academic unit that this academic unit is a child of (e.g. College of Engineering)

Important Notes:

• Academic Units must be ordered from top to bottom (e.g. University > Course)
• The Parent Academic Unit must be of the Academic Unit Type that is directly above the academic unit
  • E.g. CS 101 cannot be the Parent Academic Unit of ClassRanked University
    • Explanation: A Course cannot own a University.
  • E.g. CS 101 (Course) cannot have a Parent Academic Unit of ClassRanked University
    • Explanation: The University Academic Unit Type does not directly own the Course Academic Unit Type.

Step 3: Upload and Validate

Upload the CSV into the system. ClassRanked will automatically validate:

• That all abbreviations match what's used in Course Section data.
• That there are no structural loops or duplicates.

Step 4: Assign Admin Ownership

Admins can be assigned at any level of the hierarchy. If an admin is set as the owner of a top-level unit (e.g., a College), they will automatically get access to all units nested underneath. This ensures simplified and scalable permissions management.

To learn how to assign admins please refer to the Term Setup Guide.

Interaction Between Levels

Each level in the hierarchy nests cleanly under the one above it, based on the defined Academic Unit Types.

When reporting or configuring surveys:

• Filters can be applied at any level.
• Aggregates roll up from the section level to their parent units.
• Comparisons can be made between units at the same or different levels depending on the report design.

Final Notes

• If you’re unsure how your school structures its data, consult your registrar or institutional research office.
• Changes to the hierarchy can be made anytime, but it’s best to finalize before launching your first survey.
• If using a SIS integration: We recommend that the lowest non-Course level of your hierarchy be the level that your Student Information System or Data warehouse recognizes - this will simplify syncing data between the two systems.