With Graduation Over, What's Next for your Education Technology Department

Now that this school year is over, and the graduation parties are done, what do we do with accounts for the students that just graduated. The practice/policy varies across districts for several reasons. Some disable the accounts immediately and delete them shortly afterward. This is simple and straightforward as long as you follow the guidelines that we warned about in this post: To Delete or Not to Delete. To summarize that post, you should never delete accounts from Active Directory, eDirectory or Google until you are ready to delete them from all of your directories at the same time.

The benefit of immediately disabling student accounts is the mitigation of risk for the district. If a recently graduated student misuses their account they put the district at risk of being potentially liable.

Despite that risk, or possibly because they haven’t thought about the risk or experienced first hand what can happen, many districts allow their seniors to keep their accounts active for quite some time. Many districts allow this until sometime in the fall because students were encouraged to use their K12 school account when communicating with colleges and universities that they were hoping to attend. My experience is that most leave them active through December of the year that they graduated, but some are even longer than that.

The students can learn how to transition from their K12 school account to a personal account. Google has a process for doing this, and it is very straightforward. Many schools that have written up their procedures for doing this. A quick Google search will give you several examples to start. Here is a link to Google’s own reference page. 

Students should be encouraged to use this process to transfer what they need BEFORE they graduate so that there can be a clean break from their K12 school, and nobody has to deal with inappropriate behavior or abuse of privilege. Plus, the students can transfer any data or work they want to save. However, if you do allow your students to keep their accounts, now you must deal with the question of how to technically make that happen. Of course, it depends on whether you are still managing your accounts manually or choosing an automated solution like Student Provisioning Services.

At SPS, we can only do what the data tells us to do unless we build in ways to deal with exceptions to the rules. We discussed managing exceptions here, but it wasn’t made clear that graduated seniors could be one of the categories of students that might fit here.

We mentioned having an “Out of District” group in Active Directory to override the default behavior to suspend an account in Google that is disabled in Active Directory (or eDirectory). If we move graduated seniors into a group like this before they graduate, we can move them into a different OU in Google that removes most applications, but still allows them to access Gmail and Google Drive. This can be true no matter where their account lives in Active Directory or whether it is enabled or disabled.

It is important to remember that GCDS rules apply like firewall rules. The first match wins. That means this rule must move to the top so that it overrides anything that comes after it and wins.

The downside to this strategy is that it still requires some manual intervention. Here at SPS, we are obsessively pursuing solutions that require no manual intervention at all. We want your students to be handled properly, but to have that happen automatically without any manual effort from Technology people who are usually very overworked and understaffed.

That requires us to take a much closer look at the data and have conversations with your student data coordinator. For example, in Ohio, this person it the EMIS Coordinator, but every district has a role responsible for reporting student data to their state government. 

Taking a deep dive into the data has shown us that every Student Information System handles this differently. The top SIS’ that we support are PowerSchool, Infinite Campus, SkyWard, and ProgressBook, among others. The key to automation, no matter which SIS you are using, is being able to uniquely identify these students and handle them differently. Some districts identify their graduates as withdrawn from school. This makes them inactive in the SIS, and so naturally, we disable them in the local directory unless we have built-in an exception, they will become suspended in Google.

Some PowerSchool districts leave them active but change their grade to 99. This practice makes it very easy to uniquely identify these students and create rules or programming logic that places them in a different OU in Active Directory, then moves them to a different OU in Google with rules that are appropriate for them. This is the best way to attain the hands-free automation that we strive to deliver.

Even if a district codes these students to stay active throughout the summer months, they are eventually removed from the system when the rollup to the next school year happens within the SIS. We can intervene and still allow these accounts to remain active, but the default behavior would be that at rollup, they are disabled in Active Directory and suspended in Google.

We hope that this has given you some actionable information on how to manage your graduating seniors. If you would like our help in creating a solution that is as hands-free as possible, please schedule a demo, and we can talk through how automation looks for your district. 

Would you like to automate provisioning for your district?

Managing student passwords can be a big challenge at all grade levels in a learning community. Download our Guide to Password Management to learn about best practices for continuity in student learning and security.