Managing former employee data in any IT system can be tricky, but Google has seen fit to make it a bit harder than usual. Every organization has people leaving constantly, and large orgs might be processing dozens of people a month. For small orgs, it’s not clear what you should be doing in the first place – Google’s documentation on employee lifecycle management is pretty scant.
Third-party software like Bettercloud can help ease the pain, but it’s expensive, especially if you only need a tiny slice of the functionality it offers or are a nonprofit or small organization.
I’ve been a Workspace admin for about six years now, and have some tips on how to manage the employee lifecycle in Workspace easier. Even better, you can to do it for free.
step zero: legal fun!
Retention settings are critical to understand, especially given the rise in region specific legal requirements for data collection. You should understand how long you need to keep Gmail, Calendar, and Drive data.
If you don’t have specific legal requirements, a good place to start might be to keep former employee data for 30 days, and the data of any user involved in a legal case for the length of the case plus 30 days.
We’ll look at the three major Google apps – Gmail, Drive, and Calendar – and how to offboard users with minimal disruption. These steps assume you keep the user active for 30 days post termination.
Let’s start with the easiest application – Calendar.
A Super Admin has edit access to all calendars in your domain. The Super Admin can go to calendar.google.com, click “add calendar” to add the former employee’s calendar, click “settings” on the calendar, then add their manager / a current employee to the calendar. This works just like adding a user to your own calendar, except that Super Admins can do it for other users, not just themselves.
You can also transfer a calendar or cancel all their events before deleting a user.
You’ll need to make one major decision concerning your former employee’s Drive data – do you want it to go to another active employee, or a service account? In the service settings of Drive in the admin console, Super Admins will see a transfer section where they can transfer a user’s content to another user (not a Shared Drive – come on, Google!).
Transferring to another user
Transferring to another user will make the target user the owner of all content, and they’ll see a folder titled with the email of the former user in the root of their My Drive. All the former user’s content will be inside that folder, as it appeared in their My Drive (folder structures are retained). This can be disruptive as the new owner can get requests to share content they don’t know exists, or who should have access, but ensures an active user always owns content in your domain.
Transferring to a service account
Transferring the content to a dedicated service account will cost you a license. However, this frees current users from needing to make decisions about content. Anyone with edit access to the content under the former employee still has it, which is usually enough for most users to do their work.
But because a service account is the owner, nobody will see file access requests by default, and moving the content to a Shared Drive becomes more complicated. IT can ensure they have delegate access to the email inbox of the service account to catch file requests, and talk to users on the former employee’s team about moving critical content to a Shared Drive.
With Gmail, things can be more complicated. you have three major choices to make: whether to alert external contacts with the vacation responder, whether to forward or delegate mail, and how to store mail long-term (if needed).
Normally, an admin can only set a vacation responder or setup forwarding/delegation by resetting the user’s login info, logging into their account, and changing the settings. This is time-consuming and annoying.
If you are willing to invest a little time, there’s a tool to make this much easier. I strongly recommend setting up GAMADV-XTD3 with your Super Admin account (I’ll refer to it as GAM going forward*). With GAM, you can set the vacation responder, forwarding settings in a snap. GAM is like a user-friendly wrapper around the Google Workspace APIs. For example, if you’re offboarding ten people at once, you can give GAM a Google Sheet with their usernames and a custom vacation response message for each and be done with one press of the enter key.
Let’s resume looking at our options to handle emails.
Do you want to set a vacation response on the user’s account to alert anyone emailing them they have left the company? You can write a custom vacation response and set it with GAM if you do.
You can’t get granular with vacation responders – it’s on, or it’s off. Whether you want others to know about the employee’s departure from an automated email or not is up to you.
Forwarding vs delegation
Do you want the former employee’s mail to be forwarded to a current employee? Or, would you like a current employee to have the ability to view the former employee’s mailbox as a delegate? There are pros and cons to each.
Forwarding is a safer option, but potentially more disruptive to the current employee receiving the mail. You can use GAM to set a forward on the former employee, and then use it to set a filter and label on the current employee. Filtering the mail (skipping the inbox) and tagging it with a label can help avoid overwhelming the current user with mail.
Sometimes, forwarding isn’t enough. Users will want to access a former employee’s inbox to find a specific message or make sure communication with a client hasn’t been dropped.
Delegation introduces additional risk that a current employee may see something they aren’t supposed to see, so it should be used with caution. Delegates have almost full control over the user’s mailbox – they can read all mail, send new mail, and so on. They only have partial access to the settings on the mailbox, however. You can set delegates easily with GAM.
Handling mail long term
Do you need to store mail long term? Probably not, but you may want to keep something just in case. Archiving a user is the easiest way to keep user data long term, but it can still be a steep cost if you churn accounts frequently (like in a volunteer organization) or never delete anyone.
For former employees involved in an active legal matter, it’s best to archive them, so their data is retained in Google Vault.
For everyone else, you can save some money if you’re reasonably confident you no longer need their data – just delete their account.
If you’re really worried you’ll need some of their mail later, Google Takeout allows you to export a user’s mailbox to the open-source MBOX format or the Outlook-specific PST format. If you don’t already pay for Outlook, choose MBOX. You can use Thunderbird and a plugin to read MBOX files for free. You can store the MBOX files in your account, or the Drive service account you use for backups.
There is no API for Google Takeout, so you will need to log in to the account manually to complete the takeout process.
Let’s run through an example of everything above to show how it all works in practice. Bob leaves the company and his manager is Alice. At 5pm on Bob’s term date you – the Super Admin – start the term process.
You start by executing the GAM command to log out Bob from all his devices and remove his sign-in cookies. You can also suspend (and then unsuspend) Bob’s account via the Admin Console to get the same effect. Bob won’t have access to his work account anymore, and we can continue with transferring his content to Alice.
You start by accessing Bob’s calendar and adding Alice as a calendar manager (allowing her to change events and manage sharing). Alice can now change ownership of Bob’s recurring meetings to her, another team member, or delete meetings she doesn’t want anymore.
You then move Bob’s content to Alice. In a few hours, Alice will see all of Bob’s content in her My Drive in the email@example.com folder. Alice decides to move some of the content to her team’s Shared Drive to prevent this from happening again. The rest she keeps, and will be moved to someone else when she leaves the company.
Finally, you use GAM to set a vacation responder on Bob’s account. You also forward his mail to Alice. While you could forward Bob’s mail with a routing rule in the Admin Console, using GAM to apply it as a user setting saves you a step later – when you archive or delete Bob 30 days from the now, the user-level forward rule will no longer apply.
Before finally deleting Bob, you transfer or delete his calendar and decide to archive his content. You turn off Bob’s 2-step verification, reset his password, and login to his account using an Incognito window or a new Chrome Profile. You use Google Takeout to download his MBOX archive of his mail, and save it to your own Drive account.
I think the above flow should work for most small and even medium organizations with low churn. I’ve worked with a lot of small orgs where price is critical and free is good!
For medium or larger orgs, performing all these steps for each user manually get to be a pain. Luckily, you can run batch jobs with GAM – if you process most of your leavers in bulk, like on a Friday, this can save you enough time to not worry about changing your process to much.
If even the bulk processes start to grate because of all the exceptions (oh Admin, so-and-so wants mail for 60 days, we want to give managers calendar in all cases except salespeople, and so on), there are still options for you. At this point, you might want to buy 3rd party software like Bettercloud.
Or, you can do what I did: automate all of the above steps with Google Apps Script. More on that in a future post!
I hope this helps, and if you’ve got any questions, please feel free to leave a comment below or tweet at me.
* GAM was originally written by a now-Googler and is still maintained, unofficially, by that Googler. The maintainer of GAMADV-XTD3, who is not associated with Google, forked GAM and added features to it. Both are still maintained as of 2023.