An often unanticipated result of user account deletion, orphaned classes in Google Classroom keep cropping in G Suite forums and support desks across the education ecosystem. Schools likely don’t know they have this problem until it becomes a larger issue. So what are orphaned classes, how can they be prevented, and how can you fix them?
What are orphaned classes in Google Classroom?
When a user account is deleted in G Suite, the admin is prompted to transfer user data (Drive, Calendar, and Google+) to another user account. This does not include Google Classroom classes, so any active classes owned by a user who is deleted enter an orphaned state, showing “Unknown User” as the Owner on the Classroom homepage, and in the Stream.
The bigger problem, however, is that students in an active (e.g. non-archived) class can continue to communicate with one another in the Stream if the settings permit students to post and comment. This leaves student communication essentially unchecked, and it is likely that district admin will not realize orphaned classes even exist until there is a problem.
How can you prevent orphaned classes?
While there are actions you can take on orphaned classes, it’s best to be proactive rather than reactive — once a Classroom owner is deleted, it’s much harder to fix orphaned classes.
First, let’s outline what happens in Google Classroom when a user account is deleted:
Any active classes remain visible to students.
The teacher is changed to “Unknown user” in the Stream and Classwork pages.
The teacher account is removed completely from the People page.
Because the class has entered this orphaned state, there are limitations on the actions that can be made against it via standard remediation routes, like the Classroom API Explorer and GAM. While you can remove students and change the state (delete or archive the class), you are not able to add students or co-teachers to the class, nor can you change its primary owner. This poses a major problem, since you may need to retain the integrity of the class for the new teacher, or for retention of student and teacher communications in the Stream. Existing co-teachers can still access the class when the primary teacher is deleted, but ownership cannot be transferred.
To prevent orphaned classes from becoming an issue at your district, we first recommend avoiding the deletion of teacher accounts, opting instead to suspend them. While this is best practice for general information retention, it also prevents Google Classroom classes from entering an orphaned state, as classes connected to a suspended teacher account do not fall prey to any of the issues that affect deleted users. While the account is suspended, you can use the API methods listed above, or tools like Little SIS for Classroom, to make bulk ownership changes on the user’s Google Classroom classes.
If you do delete user accounts after a time, it is best practice to ensure that the users do not own any active or archived classes before you delete them. You can do this by making a simple list request in the API Explorer, or through the GUI Explorer in Little SIS. If you find this user owns classes, it’s recommended that you then transfer ownership to a placeholder account, or to the replacement teacher account.
Have no fear, if you have deleted the user within the past 20 days, they can be recovered with their Classroom ownership restored, and you can perform take steps to resolve the issue before permanent deletion.
How can you fix orphaned classes?
If you’ve deleted user accounts, and you later find that they are the owner of Google Classroom classes, you’ve unfortunately entered “orphaned Classroom purgatory.” There are some steps that you can take in a pinch, but they will not retain or grant access to the Classroom Stream.
If your primary concern is the immediate prevention of further communication in the orphaned class, the best thing to do is to archive it. This can be done via the API Explorer for individual classes, or via GAM or Little SIS in bulk. Archiving the class does not get rid of the content in the Stream, but does remove the students’ ability to access it. If there was a co-teacher in the Classroom they will still be able to access the class and Stream data — you cannot, however, add a co-teacher at this point. You can also remove the students from the Classroom via the same methods, but you will not be able to add a new student to the class.
While you are able to delete orphaned classes, if there are students in the class and thus any possibility of Stream data, deleting the class will also permanently delete this data. This is not recommended except in cases where classes are devoid of students, or you’re sure there is no data in the Stream that may need to be retained.
At Amplified IT, we have been following this issue closely over the past 12 months, and have been engaged with the Google Classroom team to work toward a resolution. While some of the steps outlined above can help prevent further incidents from occurring in orphaned classes, ultimately the best approach is to add a Google Classroom check to your user deletion workflow.
Data, Implementation, and Engagement Consultant
About the Author:
Melanie lives in Virginia and is based in Amplified IT’s home office located in Norfolk. One of the first members to join the Amplified IT team, Melanie has worn many hats at the company. She most enjoys interfacing with customers and helping them implement tools that solve common pain points and frustrations. Today she leads the onboarding and interfacing with Labs tool clients, making lives easier and breezier one implementation at a time.