"Current" Columns in Custom Reporting - To Use or Not to Use?

To Use Or Not To Use?

Illuminate’s custom reporting offers numerous “Current” columns: Current Site, Current Grade Level, Enrollment is Current, Roster is Current, etc. There are pros and cons to using these “Current” columns.

In my experience, users routinely use these “current” columns without fully understanding the consequences/implications of using these columns. This document will help you understand those pros and cons and help you make a more informed decision about if or when to use these “current” columns in your custom reports.

PROS:

• The data in the “current” fields is always current, always up to date. That is why they exist. If you want your report to always show a student’s current site, or current grade level, then using these “current” fields can be very useful.

• Your BI Tool Report(s) that use these “current” columns may not need to be rolled over each summer. (I emphasize the word “may” because this depends on what other data you have in your custom report. Some reports using “current” columns may contain other columns that need to be rolled over.)

CONS:

• Any custom report that uses one of these “current” columns will never return any data while school is out of session, no matter what you do to the "Control Panel". As a result, any BI Tool Reports linked to these custom reports will also return no data. If you choose to use any of these "current" columns in your custom report, you are deciding that this report will never run when school is out of session.

  • Changing the "Control Panel" date will not resolve this issue.

    • It is a common misconception that changing the Control Panel date will affect a student's "Current Site" or "Current Grade Level", etc. in a custom report. This is not the case.

    • It can be helpful to think about how this works in terms of layers of filtering:

      • The first layer (controlled by the Control Panel) asks, "Which students should be included in the report?"

      • The second layer (controlled by the columns & filters in the custom report) asks, "What data should I show about these students?"

    • So, the Control Panel changes which students are included in the report, BUT the report will still show the current site, for those students. When school is out of session, no students have a current site. As a result, it makes no difference what you change the Control Panel to.

• Using "current" columns in your custom report means that you will not be able to look backward and see the data for previous academic years.

  • Educators often want to look back at the data from previous years. Using the "current" fields will make this impossible.

Alternative

If you've decided that you don't want to use the "current" columns, then what do you use instead?

Instead of using the "current" columns, focus your custom report on a specific academic year by using the "Academic Year" columns to filter your data.

IMPORTANT: There are many "Academic Year" columns in the custom reporting database. It's important to understand this in order to use custom reporting effectively. For example, both the Enrollment category and the Class Rosters category in custom reporting have their own "Academic Year" column.

Rule of Thumb: Whenever you add any column from the Enrollment or Rostering, etc. categories, always add the "Academic Year" column from the same category to your custom report as well. Then, add a filter to your custom report that filters the report for a specific academic year.

If you add any field from the Enrollment or Rostering categories, the report will return all of the students' historical data. For example, if you add "Site Name" to your custom report from the Enrollment category, the report will show you every single site each student has ever been enrolled at in your district. By adding the appropriate "Academic Year" field, and adding a filter for a specific Academic Year, you can get the site that any student was enrolled at, during a specific academic year.

Best Practice: Create reports that focus on a specific academic year. Then, roll over these reports every summer by (1) duplicating the report, and (2) changing the filter of the academic year.

This way, you will be able to:

1. Run the reports, even when school is out of session.

2. Users will be able to look back on past years of data.

You will end up with multiple copies of what is essentially the same report, one copy for each academic year.

If you want to avoid having copies of what is essentially the same report, learn how to use the BI Tool with SQL, and you'll be able to do just that! 😀

BI Tool Implications

If you make any changes to custom reports that are linked to BI Tool reports, you will need to make the corresponding changes to the JRXML file in Jaspersoft Studio as well. Remember, the columns in your custom report must match the "fields" in your Jasper report.* IF they don't match, the report will not run.

So, if you remove the "Current" field(s) from a custom report, and replace them with data from a specific academic year, as described above, you will also need to update your BI Tool report.

We're happy to help you with this process! Feel free to submit a help ticket by emailing [e-mail] if you would like us to walk you through the process.