Unlocking the potential of RMS Judicial

How the University of Southern Indiana learned to get more from one of their favorite old programs

by Matt Gregory
Asst. Director for Judicial Affairs

At the University of Southern Indiana, we were using RMS Judicial mainly as a database for our housing-based incident reports. Originally and several years ago, Laurie Berry our new Director of Housing and Residence Life worked closely with RMS to develop a complete and multi-faceted judicial module. The construction of the module was designed to address our record maintenance needs as well as numerous functions we had only begun to realize. Since this time, we were using RMS Judicial at USI as a basic database and as a means to track sanctions.

We like the user-friendly nature of the Judicial module. The module is set up in a process-oriented and logical sequence in regard to entering data from the creation of an incident report to the culmination of the case. The logical flow of information and screens made hearing officer training a breeze.

We struggled with using the Judicial module to the full potential. And, unfortunately, over time certain features were completely disabled or the defaults were deleted as a means to “tweak” the module to be a certain need as opposed to receiving training from RMS on how to use the module as it was intended to be used by the programmers. As a result, the version of the module we were using had been altered so much to the point that general efficiency and functionality had been severely hampered. We also struggled with the use of the auto emails to go from a paper notification process to a completely electronic notification process.

What you wanted to get out of the Judicial visit? What we worked on, how it helped and how you feel it improved your use of Judicial.
We wanted a review of the current state of our module at USI to determine exactly how much our module had been altered from the original condition and from the conceptual design of the programmers.

We wanted to maximize our use of the various features and offerings of the module to a more full potential. We wanted to work out the use of the auto email function to begin using the mail merge function for purpose of hearing letter dissemination. Lastly, we wanted to explore the use of Crystal reports to retrieve data for Clery reporting and other institutional-based reporting requirements.

We spent most of day one with a thorough review of the module including field arrangement, field content, and the condition of the module defaults. We spent the second day exploring the various functions of the judicial module including auto emails. Lastly, we spent some time learning the sequence of the data flow to optimize our use of Crystal reporting. As a part of exploring the use of Crystal to retrieve very specific data, we also had the opportunity to explore several of the new views created to provide more direct access to data contained in many of the more common tables.

We believe the benefit we received by Greg’s recent visit to USI is two-fold: Greg was able to compare the current state of our module with how the module is being used at other institutions and secondly, Greg provided helpful insight into the programmatic design of the module which gave us much needed insight into how the judicial module was designed to work and how it should be used. These two benefits helped us to restore our judicial module closer to the conceptual design of the module and increased our knowledge of the module programming enabling us to become more purposeful users of the judicial module.