+1 (740) 420 5907 blazertech@ohiochristian.edu


  • Abbie Ailes
  • Lois Moore
  • Dustin Epperly
  • Ryan Noble
  • Cindi Celske
  • Sierra Canter
  • Robin Patrick
  • Tera Kuehne

Sonis new uses for fields:

Before starting to use a field for a new purpose, please ask me about it so that 1) I can provide guidance and answer questions, and 2) So I will know about it when others ask questions about the same field (or if issues arise, I will know why the data is there and who to contact to resolve conflicts, etc.).

Change Request Form and procedures:

I discussed the new Change Request Form and the reasons for it. We only have two developers, and one is working almost full-time on Clearinghouse and Financial Aid issues. Since we do work for the entire university, we need the extra information provided in the change request form to help us determine which projects we should take on. I discussed the procedure that occurs once a form is submitted. I watch the helpdesk tickets for the dev team daily and I will grab any that I can take and handle and the others are held until the Monday Dev Team meeting. The Dev Team discusses each submission to determine which ones are doable. After the meeting, I will update the ticket with whether it was approved or denied. At some point, a developer will be assigned to it, and, at that point, will be able to offer an estimated timeframe for completion. Until it has been assigned, there is no way to know how long it will take to be assigned or how long the task will take to complete.

Submission of Tickets:

I reminded the group to submit tickets and explained why they are important. We mine those to discover issues that need to be addressed. If multiple people or departments are having the same issues, we will determine what needs to happen to resolve that issue (is training needed, do we need to code a solution, etc.). We also use those to determine topics for upcoming knowledge base articles and Friday Tech Tips. I also mentioned that if I receive an email, I may miss it, forget about it, have it get lost in the mountain of other emails. Submitting a ticket ensures it gets addressed/answered and not lost. It also ensures someone sees it and can address it when I’m out.

Knowledge Base Site:

I mentioned the Knowledge Base site (as covered in a recent Friday Tech Tip) and where those articles come from (the tickets that are submitted and questions that are asked).

Sonis Upgrade:

Discussion of the Sonis upgrade. A new test system has been set up, but will not be open to testing until after Lois finishes the 1098Ts. Once she finishes, we will start testing it for several months. We need to test it extensively so we don’t have a repeat of the Sonis 3.0 upgrade. The base system will be upgraded to Sonis 3.4, but the customizations will still look like Sonis 2.8 (like they do now). We need to test those extensively to ensure they all work properly. We plan to go live during the Summer next year and that will put us on the latest version of Sonis for another year.

I will be providing a list of reports from Sonis, with a list of who has access to those reports and what profiles those users are assigned to. I explained the way that permissions are set up in Sonis. Reports and pages are assigned to profiles and users are given profiles in order to have permissions to those pages. This ensures that each person with the same profile has the same permissions as the next without us having to go through and assign individual pages and reports to each new user. We set up profiles that have access to all the pages and reports needed in that department by that level of staff member. Then, as new staff come, they are given a profile that provides them with access (and level of access) to the same pages and reports as their coworkers. I mentioned that I will be emailing the spreadsheet and asked that each user go through the list and let me know what reports they no longer need. They can also look at the profiles and determine if someone is assigned the wrong profile (perhaps they changed jobs and never had their profile updated). I also asked that they make sure that the users listed should have access to those reports.

I went through the report listing I showed during the meeting and made some additional changes to make it easier to go through (like removing staff who are no longer with OCU). I added a notes column (highlighted on the spreadsheet) for you to add notes. Please highlight any reports that are no longer in use and type in an explanation (if warranted) in the notes column. This listing is accessible to all SUG members and can be found here: https://ohiochristian0.sharepoint.com/:x:/s/SUGFollow-up/EU7H5F8yKGFHu897Mr11I04BhV-uv9OL_IGCINruiONVZg?e=A5ZvfH.

I asked each user to look through the custom pages they have available to them and to let me know of any that they may have used in the past but no longer use now. The more we can disable, the smoother this update and future updates will go. We will be slowly rebuilding the customizations and would prefer to focus on those that are actually being used and to disable those that are no longer needed. Also, Sonis may have caught up in functionality (at the time we needed certain functionality, Sonis may not have been able to provide it, but it may have caught up to us and we can now disable the customization and start using the built-in functionality). The more customizations we can disable, the better/smoother this and future upgrades will go.


We discussed Slate and the data that may no longer exist in Sonis such as recruiters, recruitment activities, etc. As such, processes may change, so it’s important for departments to work together to figure out what processes need to be changed and who will be responsible for what. Also, reports and processes may not be complete/contain all the data you are used to seeing – and some may not work at all if they are dependent upon data that is no longer kept in Sonis. If you see this, feel free to reach out to us to see if this report is a casualty of this project or if something else is going on.

Slate and Sonis. I mentioned that I have just now joined that project and I’m working on data transfers between the two systems. There currently is not an interface between Slate and Sonis, so we need to build that…and we are wanting bi-directional data transfers, so we have to look at each field and determine what gets moved/overwritten when data already exists in the receiving system. One of my tasks is to go through all the fields and identify how they should be handled.

Dustin shared his concerns about data being overwritten. I stated that some fields should never be overwritten such as birthdate. If the birthdate is different, then it must be assumed we are looking at a different individual’s record…unless the birthdate is obviously wrong or empty. In that case, we have to use other information to determine matching records (for existing data). Dustin stated that Students, Alumni, and Withdrawn students should never have their modstat changed to Applicant. I mentioned that since we are the ones coding the data transfer, we can control that, but it has to be defined for us to know how to code it. Sonis is the authoritative database – it’s data is the root of all other systems. Sonis data is used for student records, accreditation reporting, financial aid processing, student billing, etc., so its data should not be changed unless we allow for that (as per definition…we define that it can be overwritten).

Dustin asked what happens if we bring records from Slate that already have an existing record in Sonis. I will look into whether we have already determined that, but aside from that, we NEED to determine that and build that into the process.

Abbie mentioned some things she is seeing with records. I will reach out to her for more details to ensure those things are addressed in our transfer scripts.

Faculty Records in Sonis:

Cindi asked about some of the fields on the bio page (for Faculty records). One field was the directory. I explained what the directory in Sonis is. In Sonis, students and faculty can search for other students or faculty. The directory is a list of those who opt in to allowing themselves to be searched. If that is checked, they are saying that they wish to be found by other students or faculty. In their portals bio pages, they can control what data is shown in the directory (email, phone numbers, addresses, etc.). Another field is the inactive field. We discussed whether Faculty are also students or alumni, etc. She said to be a faculty member, they must contain a Masters degree so it would be highly unlikely that they would also be students. I told her that the inactive checkbox will inactivate the faculty member. The login disabled field will keep them from logging into their portal. These fields affect all portals for this individual though, so if the faculty member were also a student, then the student login would be disabled as well. She said it is unlikely a Faculty member is also a student, so this will work for her purposes.