Offboarding Policy and Process for Google Workspace

One of the biggest concerns when users are leaving the business is the retaining of data that could be sensitive or crucial to upcoming events.

CloudM Manage provides a customizable offboarding policy and process which can be applied to your entire domain and, where required, specifically to different Organizational Units.

The workflow is a total of 32 steps that can be enabled or disabled as you require.

1. 1. Request Approval
   2. Preemptively Suspend User
   3. Prompt for Resource Allocation
   4. Wipe Mobile Devices
   5. Wipe Chrome OS Devices
   6. Change Password
   7. Revoke 2-Step Verification
   8. Remove Recovery Methods
   9. Revoke Application Specific Passwords
   10. Revoke Application User's Accounts
   11. Revoke OAuth Tokens
   12. Set Out of Office Message
   13. Remove Email Forwarding Settings
   14. Delegate Access
   15. Move User
   16. Hide User
   17. Rename User
   18. Assign Alias
   19. Archive
   20. Archive Vault
   21. Transfer Ownership of Documents
   22. Migrate Calendar Events
   23. Transfer Ownership of Groups
   24. Transfer Contacts
   25. Transfer Shared Drives
   26. Transfer Looker (Google Data) Studio
   27. Remove from Groups
   28. Migrate Emails
   29. Unassign Licenses
   30. Suspend User
   31. Apply Google Archived User (AU) license
   32. Delete User

Workflow Settings

When configuring your Offboarding policy,  the first option in Workflow settings that you have available for selection is the ability to 'Automatically Offboard Suspended Accounts'. If this option is selected, as stated, any account within the OU where this option is active that is set to a 'suspended' state will be automatically offboarded in line with the rest of the defined policy steps. Accounts currently in a suspended state when this setting is enabled will not be offboarded. You will be required to offboard these accounts manually using the normal steps. 

During the offboarding process, we are required to remove the suspended state from an account to allow the system to process documents (e.g. transfer ownership of documents). When these steps are complete, we will automatically re-apply the suspended status to any account offboarded using this method. However, it is important to remember that if you have a large account, the period of time when the account is unsuspended maybe lengthy whilst documents and email are transferred. You must take steps to secure the account to ensure no unauthorised use.

Automatic Offboarding

Next, you must set the Executor. This is the person / account that will be required to make decisions during the offboarding process

The Executor can be set to one of the following:

• User's Manager or Domain Admin
• User's Manager or Specified
• User's Manager or Error
• Domain Admin
• Specified
• User's Manager

 Multiple Executors

After setting the executor, you will see several text fields that can be edited. These fields are the email subject lines that will be received when a user goes through the offboarding process. You can alter these so you can more easily setup a Gmail filter, or ensure the language is tailored to your organization. It does not have any impact on the offboarding process itself. 

Additionally, you can set whether to "Show the user who started the offboarding in the notification emails" and Add additional recipients to the notification emails.

Workflow Actions

At this point, you will then be able to specify which steps you want on your Organizational Unit's policy. Select the Workflow actions tab to see the actions that have already been inherited from the Parent OU. You can quickly remove steps from the current workflow (by selecting the Trash Can icon at the end of the row) and just as easily add steps by selecting the Add offboarding step button.

This will prompt a panel to slide in (replacing the Org Units list) from which you can select the required steps and they will automatically be placed in your current workflow in the required order. Select Save to confirm any changes.

The Offboarding steps are:

1. Request Approval - This is a basic Yes / No request to the Executor. The purpose is to ensure manual approval is given before the process begins.
2. Preemptively Suspend User - This step will allow you to suspend the user at the start of the offboarding process, preventing them from logging in and accessing any services from the account. This step is ideal for workflows that include custom delays between steps.

3. Prompt for Resource Allocation - Since we allow you to reallocate items to default values (which can be changed in this workflow from the Executor), we also allow you to change who this is going to be at the last second, without having to go into the workflow and altering the policy for everyone. This is useful if a colleagues files or alias could be better suited to someone else's account, such as a team member or an archive account.

   • It's important to note that there are sub-components that can be disabled if you don't want to give the option to reassign specific items, i.e. you could have it so that only drive could be re-assigned but all other items will always abide by the workflow.

4. Wipe Mobile Devices - This clears any corporate data connected to the user account on any devices owned by this domain. The mobile devices must be configured through device management in Google Workspace Admin portal.
5. Wipe Chrome OS Devices - Remotely wipes user accounts from any Chrome OS devices owned by the user. Please note that this step does not support Enterprise controlled Chrome OS devices.
   • To remove user data from a Chrome device, the 'WIPE_USERS' command needs to be invoked from the ChromeOS API.
6. Change Password - Changes the user's password to a random 16 character alphanumeric one to prevent log-in and clears their password reset question answers.
7. Revoke 2-Step Verification - If the user has configured two form authentication for their user account, this option will revoke any of this data upon offboarding as an added layer of security. This includes turning off 2 Factor Authentication if enabled in Google.
   • If a user is suspended and this step is triggered, the user is unsuspended and an hour wait is triggered before the step is done. Then. the user will be suspended again once the step is completed.
   • If the user's 2-step verification is managed by a Google policy, such as at OU level, then the step will not error but CloudM will be unable to disable their 2-step verification.
8. Remove Recovery Methods - Removes the Recovery Methods (recovery email and phone number) currently setup for the user so they cannot change the password back and gain access to their account.
9. Revoke Application Specific Passwords - Revokes all application specific passwords created for the user's account. This prevents applications from accessing the user account on their behalf.
10. Revoke Application User's Account - Revokes access to user's accounts in other applications (e.g. Slack). This prevents the user from logging into the application. All installed integrations are selected by default, or you can specify which applications to apply the workflow to.
11. Revoke OAuth Tokens - Revokes all OAuth tokens issued for the user. This prevents applications from accessing the user account on their behalf.
12. Set Out of Office Message - Sets the Out of Office message for the user. The Out of Office message is a template that can include profile attribute placeholders just like email signatures. The email address of the specified Out of Office Contact user can be included in the message with $contact.
13. Remove Email Forwarding Settings - Remove the Email Forwarding settings configured for the user. Emails sent to the email address will no longer be forwarded.
    • For example, this step would stop a leaver from being able to set up forwarding to a personal account.
14. Delegate Access - The specified recipient will be given delegation access so they can read/send/delete messages on behalf of the user. 
15. Move User - This moves the user profile to a specified OU.
16. Hide User - This hides the user profile from the global address list so no other user can find them. 
17. Rename User - This renames the user's primary email ID, first and/or last name.
    • Renaming the user's primary email ID allows the same email address to be re-used by another user immediately. The user's new primary email ID / first name / last name is based on a template which can include profile attribute placeholders just like email signatures. The primary email ID template can be a full email address (e.g. old.$mailPrimary) or just the username part. If any template is empty, a random ID is generated.

18. Assign Alias - This option is only available if 'Rename user' is enabled. Reassign the leaving users primary email to the new owner. A label can then be specified and this will be applied to all emails coming into the new owners mailbox but when using the old users primary email as it's now an alias. This helps avoid disruption of the new owners workflow within Gmail and means they can easily find and update any and all clients emailing an invalid address. 

19. Archive - Archives the user's data to long term storage which can be restored to another user account at a later date. If the offboarded user does not have any mail services enabled, such as a Google Cloud Identity Account, this step will be skipped. The step will only be visible if Archive has been enabled on the domain (refer to Adding the Archive step to an Offboarding Workflow for more information).
    • Fair use policy - Each user (identified by the User ID) can only be archived for a maximum of 5 times, by default. CloudM Archive will display an error if this level is exceeded. The Fair Use Policy is an existing part of the terms and conditions for CloudM Archive.
20. Archive Vault - Archives the user's Vault data to long term storage which can be restored to another user account at a later date. The step will only be visible if Archive has been enabled on the domain (refer to Adding the Archive step to an Offboarding Workflow for more information).
21. Transfer Ownership of Documents - This moves over all documents from the leaving user to the new owner and puts it all under a root level folder in their MyDrive as specified under the new owner setting. This means your MyDrive structure is unaffected but can now find all files of the leaving user easily.
    • Enforce Only Transfer Shared Documents - Only transfer items that have been shared with other users.
    • Use Data Transfer Api - Use the Google Data Transfer API to transfer the ownership of the documents instead of the existing CloudM method. Please note that the Google Data Transfer API will not grant the same level of error logging or statistic reporting fidelity as the CloudM method. Please refer to the Google Data Transfer API use case and limitations article for more details on differences and limitations.
22. Migrate Calendar Events - The user's primary calendar will be cloned and migrated with a name based on the template below which can include profile attribute placeholders just like email signatures. Incoming events in the cloned primary calendar are disconnected from the originals, meaning changes by attendees are not reflected in the cloned event and vice versa. In addition, recurring events in the cloned primary calendar are expanded into individual events, meaning changes in one will not be reflected in the other occurrences. Without this step any calendars the user has created will be lost. Ownership of the user’s secondary calendars will be transferred.
    If the offboarded user does not have any mail services enabled, such as a Google Cloud Identity Account, this step will be skipped.
    • The Migrate Calendar Events step now includes a Remove Resources from Migrated Events check box which allows the administrator to decide to remove resources or retain resources during migration (such as Meeting Rooms, Jamboards etc), freeing them up for use.

23. Transfer Ownership of Groups - This moves all groups over to the new owner. If Groups is not selected, they will be lost when the user account is deleted.

24. Transfer Contacts - This will move all contacts over to the new owner and place them under a name you can specify under the new owner setting, If Contacts is not selected, they will be lost when the user account is deleted. 

25. Transfer Shared Drives - This will transfer the ownership of any Shared Drive where the offboarded user is deemed the owner to a new owner. By default, the new owner is set as the Executor, but you can specify a different owner within the policy.
26. Transfer Looker (Google Data) Studio -  This step will transfer the ownership of Looker Studio (previously known as Google Data Studio) data to a specified user. 
27. Remove From Groups - This will remove the user from any groups they're a member of, but it's important to note with any smart groups they may be re-added if they still fall under the search query the group is based on. That is why it can be useful to move the user to another OU (under Hide user step).
28. Migrate Emails - Migrates the user's emails to the specified user. The migrated emails will be given a label based on the template below which can include profile attribute placeholders just like email signatures. The original labels of the migrated emails will be re-created under this new label.
    • • When enabled, the Disallow Label Truncation setting will fail the step if a label is too long. When disabled, the step will not fail but will use the label of the closest parent instead.  
29. Unassign Licenses - Unassign all Google licenses from the user so that they are returned to your license pool. This prevents offboarded users from using up a valid license that could be assigned to an active user, helping you to keep your license costs under control.
    • • If the user has auto-licensing enabled, the license will not be removed using this step.
30. Suspend User - This prevents the user from logging in and accessing any services in Google Workspace.
31. Apply Google Archived User (AU) license - Switches the license on the account to a Google Archived User (AU) license.
32. Delete User - This finally deletes the profile in full. You can provide a delay and also set reminder email delay values. 

You can add a custom delay to any step (except where the step requires manual input) so that steps do not automatically start after the previous one has finished, and can be more inline with your offboarding timelines.

To add a custom delay:

1. Add the step to your Offboarding Workflow,
2. In the row for the required step, click on the Clock icon.

3. Configure the delay (in days) before the offboarding step is executed.
   • The value must be a full integer (e.g. 1, 2, 3 etc.), and cannot be a part number (e.g. 1.25, 1.5, 1.75 etc.)
   • Entering a value of 0 will remove the delay.
   • Place a check in the Send email notification before delay end checkbox to trigger a reminder email (that the specific step delay is coming to an end) to be sent to the notification email recipients set in the Workflow settings section. The notification will be sent 24 hours before the end of the delay.

4. Select Apply.