Tracking Community Service

hps-habitat-for-humanity-2014-09-20Hanover High School recently updated its graduation requirements to include a community service component. Starting this year, every high school student must log 10 hours of community service each year from grades 9 through 12 in order to graduate. As the school year progressed and students started submitting paper forms for their service hours we knew we needed something better than a spreadsheet to track the data. After some basic configuration, a few small customizations, and one workflow we were able to enter, view, and summarize the community service data all from Aspen. Keep reading to learn how we got all this up and and running.

Step 1: Storing the Data

Our first step was to decide where to store the community service data in Aspen. We wanted to track the list of individual service events for each student. The events would have a category, a date, and the number of hours served. We also wanted to tie each event to the school year so we could tally the community service hours for each grade level the student was in. We decided to use the Student Event Tracking table – it is a child to the Student table and it is related to the School Year Context table. Once that decision was made all we had to do was define user fields to track the individual bits of data – six fields total. We set aliases on all these fields to help make the related customizations portable for other districts to use.


Click for full-size image

Step 2: Displaying the Data

Student events can be viewed one student at a time (Student > Transactions > Events) or globally (Global > All > List). We created custom field sets to display our new community service fields. Also, since we track other data in the Student Event Tracking table (like excessive absence letters), we created filters to quickly show only community service records. As you might have guessed, we also customized the Student > Transactions > Events > Details template (student.std.list.trk.detail) to include our newly defined user fields.


Click for full-size image

We took this one step further and created a dynamic template to only show the community service fields when the event’s type was set to the “Community Service” reference code. This is similar to how the Visit > Daily Log > Details template behaves in the Health view: the template changes based on the primary complaint. This was done via a <switched-include> tag in the template’s XML (line 19):

<?xml version="1.0" encoding="UTF-8"?>
        <property id="trkEventDate" />
        <property id="trkEventType" />
        <property id="relTrkCtxOid.ctxSchoolYear"
          <picklist relationship="relTrkCtxOid" required="true">
            <field id="ctxSchoolYear" sort="true" />
            <field id="ctxContextName" />
    <switched-include id="eventTypes" context="dynamic.eventTracking" property="trkEventType" />

We then set the Template Context on the codes within the Event Type Codes reference table to either “.default” (for absence letters) or “.communityService” (for community service):

Code Description Template Context
Absence Letter 5 Letter for 5 or more absences .default
Absence Letter 10 Letter for 10 or more absences .default
Absence Letter 15 Letter for 15 or more absences .default
Community Service Community service event .communityService

Finally, we created two templates with contexts beginning with the context attribute in the above <switched-include> and ending with the Template Context values set on the reference codes:

  • dynamic.eventTracking.default
  • dynamic.eventTracking.communityService

The first template simply displayed the comment field. The second template displayed the six community service fields defined earlier as well as the comment field. (You might be thinking, “Why not put the comment field in the parent template since it’s used in both included templates?” Good question. It’s important that the default template contains at least one field otherwise you’ll see an empty row with the message “No accessible fields.” Not very pretty.)

Step 3: Entering the Data

Eliminating the paper community service form would save trees as well as data entry time – this was a top priority from the very beginning of the project. The obvious way to do this was with a custom workflow. Students were able to initiate a workflow and enter the details for their community service. Once they submitted the form, the workflow was routed to the front office secretaries who reviewed and either approved or rejected the submission. Students received an email once they submitted their request and then again when the request was either approved or rejected. The emails also told the student how close they were to meeting the annual 10-hour requirement.

The workflow itself was modeled after the system-defined Conduct Referral workflow. The first phase simply gathered data from the students and the second phase posted that data to the Student Event Tracking table. Custom Java code was used to send the emails. Click here to download the workflow from the wiki.

We added a Workflow widget on the Home page that was visible in just the Student view to simplify the initiation process. Rather than having to select a workflow via the Tasks widget and going through the three-step wizard, students could simply click Initiate…, complete the form, and click Save. (Thank you Derek Leadbetter and Brian Converse!)


Workflow widget


Embedded form

Step 4: Analyzing the Data

It was important for the high school principal and his team to analyze the community service hours logged by the students. Built-in list tools like Quick Report and Quick Chart were helpful when run from the global list of Student Event Tracking records but we wanted to simplify the process even more. We created two Analytic Definitions to summarize the data (click the links to download them from the wiki):

Both of these analytics were scheduled to run nightly to keep the data current. The analytic results could then be summarized even further by using Quick Report to export the data to Excel via a CSV file.

Step 5: Sharing the Data

Our final step was to share the community service information with students and parents on the quarterly report card. We added an option to “Show community service hours” on the “Report Card” report (not selected by default since our middle school shares this report with the high school). When selected, the Java source sums the service hours in the selected school year for each student and displays the total on the report format in a message like this:


Click for full-size image

The specifics for this customization can be found here: community-service-report-card-snippets.txt (Hanover’s “Report Card” report was too specific to our district to be worth adding to the wiki).


As you can see, Aspen’s extensibility is quite impressive. With no built-in module for tracking community service we were nevertheless able to create a rich set of features that allowed our high school to manage the entire process within Aspen.

I hope you’ll be inspired to extend Aspen’s core features and combine customizations to create even greater functionality for your district. Let me know how it goes in the comments below!

Leave a Reply